|
Xarn posted:Preventing binaries that use str(n)cpy from running sounds like a feature. Yeah, I put strcpy there for that reason. I still think that omitting terrible features in a standard library is going to break existing code, and in ways that are difficult to track down. (Deleting a single function is a no-brainer to track down. Changing the semantics of /deleting a certain edge case is going to be mysterious.
|
#
?
Jun 26, 2019 21:27
|
|
|
|
| # ? Jun 7, 2024 21:31 |
|
|
Qwertycoatl posted:They talk about a growing range of needs they can't get from existing libcs, but don't say anything at all about what those needs are. I wonder why they want to reinvent this particular wheel. Their library developers need something to do.
|
|
#
?
Jun 26, 2019 21:32
|
|
|
There is nothing wrong with strcpy unless your complaint is really the entirety of null-terminated strings. EDIT: I was thinking of strdup rjmccall fucked around with this message at 06:51 on Jun 27, 2019 |
|
#
?
Jun 26, 2019 21:59
|
|
|
ultrafilter posted:Their library developers need something to do. Yeah, I agree. I'm pretty sure some team needs to justify their existence so they swung for the fences.
|
|
#
?
Jun 26, 2019 22:05
|
|
|
rjmccall posted:There is nothing wrong with strcpy unless your complaint is really the entirety of null-terminated strings.
|
|
#
?
Jun 26, 2019 22:18
|
|
|
Funny, Mozilla is already developing a better standard library for C
|
|
#
?
Jun 26, 2019 22:39
|
|
|
rjmccall posted:There is nothing wrong with strcpy unless your complaint is really the entirety of null-terminated strings. There is when strncpy exists.
|
|
#
?
Jun 26, 2019 22:47
|
|
|
ratbert90 posted:There is when strncpy exists. strncpy is not a safer strcpy. strncpy doesn't even guarantee that you'll end up with a null-terminated string. even if you avoid that gotcha, there is no way to detect when strncpy truncates the input, and it is needlessly inefficient if the input does fit. you should never ever use strncpy to copy strings.
|
|
#
?
Jun 26, 2019 22:57
|
|
|
strlcpy is the preferred alternative to strcpy. It's not part of the standard, but it's generally available.
|
|
#
?
Jun 26, 2019 23:01
|
|
|
ultrafilter posted:strlcpy is the preferred alternative to strcpy. It's not part of the standard, but it's generally available. Ooh, nice.
|
|
#
?
Jun 26, 2019 23:04
|
|
|
Is there a coding blog horrors thread? I just found this brilliantly bizarre post:quote:First, imagine an angel. The angel radiates a soft, pure white with glittering wings and a serene face. They bob gently over the ground and moves with smooth yet purposeful grace. No living person can see this angel, and it passes through anything it touches. So, yeah. What was that supposed to be explaining? Functional vs imperative JavaScript, obviously. https://dev.to/maxwell_dev/a-metaphorical-introduction-to-functional-javascript-3og4
|
|
#
?
Jun 26, 2019 23:16
|
|
|
ultrafilter posted:strlcpy is the preferred alternative to strcpy. It's not part of the standard, but it's generally available. for values of "generally available" that exclude obscure platforms like (checks notes) uh, linux and windows yeah you can use not-glibc on linux but mainstream is all glibc. there's probably a non-standard libc for windows too but microsoft really want you to use strcpy_s, or preferably not c at all. or you can just include a standalone implementation of it, but at that point why aren't you just using an actual string library that just stores the lengths so you can have things like a string length lookup that isn't O loving (n)
|
|
#
?
Jun 26, 2019 23:16
|
|
|
EDIT: oh gently caress I’m thinking of strdup
|
|
#
?
Jun 26, 2019 23:20
|
|
|
Kazinsal posted:I like the idea that they seem interested in writing a safe, statically linked libc. That has positive implications for embedded applications. ah yes, my safe statically linked libc for embedded applications that's, uh, *checks notes* x86-64 only
|
|
#
?
Jun 26, 2019 23:24
|
|
|
Soricidus posted:why aren't you just using an actual string library that just stores the lengths so you can have things like a string length lookup that isn't O loving (n) 
|
|
#
?
Jun 26, 2019 23:26
|
|
|
ultrafilter posted:strlcpy is the preferred alternative to strcpy. It's not part of the standard, but it's generally available. Isn't strncpy_s part of the C11 library? Does the same thing but theoretically safer since it also intercepts NPEs and does some bounds checking. JawnV6 posted:ah yes, my safe statically linked libc for embedded applications I said I liked the idea, not the execution
|
|
#
?
Jun 27, 2019 00:10
|
|
|
Kazinsal posted:Isn't strncpy_s part of the C11 library? Does the same thing but theoretically safer since it also intercepts NPEs and does some bounds checking. it's an optional part. many libcs don't implement it, and it might be removed in future versions. pretty much only microsoft likes it and they probably only put it in the standard in the first place in a desperate bid to persuade microsoft to move past c89 ever.
|
|
#
?
Jun 27, 2019 00:23
|
|
|
Did they learn nothing from essentially forking Java?
|
|
#
?
Jun 27, 2019 03:48
|
|
|
JawnV6 posted:ah yes, my safe statically linked libc for embedded applications No ARM support? Did a certain former glibc maintainer get a job at Google?
|
|
#
?
Jun 27, 2019 04:26
|
|
|
Absurd Alhazred posted:Did they learn nothing from essentially forking Java? It worked. For them.
|
|
#
?
Jun 27, 2019 04:31
|
|
|
rjmccall posted:There is nothing wrong with strcpy unless your complaint is really the entirety of null-terminated strings. Ding ding ding.
|
|
#
?
Jun 27, 2019 06:27
|
|
|
Seriously though, null-terminated string have the advantage of saving sizeof(char*) - sizeof(char) memory per string, for the low low cost of endless security vulnerabilities, being slower when concatenating them, being slower when copying them, their substrings cannot share the same buffer and nothing in the type system distinguishes them from a pointer to an arbitrary object.
|
|
#
?
Jun 27, 2019 06:36
|
|
|
I, too, think pointer-and-length is a much better way to pass around buffers and strings. However, you need to remember that C is a very old language that evolved directly from even older languages, and they were still figuring out a lot of things that it's easy to be smug about in retrospect. BCPL and B were untyped: all values were single-word cells. If you declared an array of size N in B, the compiler set aside N+1 cells and made the first a pointer to the rest; when Ritchie was adding types in C, he wanted arrays to correspond exactly to an array in memory, so he had to invent array-to-pointer decay in order to make that work. When he added structs, they were purely for memory layout, and he had no conception that it would be useful to be able to pass them around as return values or arguments; C didn't acquire that capability until the ANSI process started in the mid-80s. BCPL stored the string length in a prefix byte on the string, like Pascal did (much later), and just like Pascal that meant that strings could only be 255 or 511 characters long (depending on the machine's byte size); B switching to use a terminator character was considered a major expressivity win because strings weren't so artificially limited in length. Apparently Ritchie considered using a separate length for C strings and decided it would be hugely inconvenient for programmers, which it really would've been if you had to pass it around yourself everywhere. (Null-termination is also very convenient for code that directly processes strings, like parsers — you're looking at every character anyway, and it's nice not having to check a separate length every time. Clang actually sets up its input buffers so that they're guaranteed null-terminated, and we only check the buffer length when we actually see a '\0', which of course is very rare in source files.) Also, you can't write a generic struct in C, so in order to have a type that can represent a pointer-and-length to an arbitrary type, you'd have to build it into the language with intrinsic constructors and projections like the C99 _Complex T type. Anyway, libc can't do anything about any of this, because if it tried, it wouldn't be libc anymore; and the compiler can't do anything about this, because if it tried, it wouldn't be a C compiler anymore. Now maybe a libc can justify removing the unsafe functions — already a stretch, frankly — but it can't just take every single function that takes a string across both C and POSIX and make them all accept a _String instead of a const char *. For one, it probably still cares about ABI for existing compiled code. Even if not, maybe someone can hack the language so that string literals convert to _String, but that won't help with the vast amount of C code that's passing in an opaque char*, or which expects library functions to return one instead of a _String. And if you're willing to go that far — changing how the language handles strings across both the compiler and the library and requiring massive code changes — you might as well aim to solve bigger problems than just pointer bounds.
|
|
#
?
Jun 27, 2019 08:24
|
|
|
rjmccall posted:Anyway, libc can't do anything about any of this, because if it tried, it wouldn't be libc anymore; and the compiler can't do anything about this, because if it tried, it wouldn't be a C compiler anymore. __builtin_object_size and __attribute__((pass_object_size)) get you a lot of the way there, while still being source compatible with standard C.
|
|
#
?
Jun 27, 2019 09:39
|
|
|
Soricidus posted:there's probably a non-standard libc for windows too but microsoft really want you to use strcpy_s, or preferably not c at all. Unlike Unixes, there isn't a standard libc for Windows at all. Your standard, shipped with the OS layer is the Win32 API; if you're selling/vending/releasing a C compiler for Windows you'll also need to provide your own libc with it.
|
|
#
?
Jun 27, 2019 10:51
|
|
|
there isn’t a single built-in libc on windows, but I feel justified in using the word "standard" to describe the libc provided by the platform vendor with their c compiler. (yes, I am aware there are multiple versions of this libc. no, I don’t care.)
|
|
#
?
Jun 27, 2019 11:09
|
|
|
Well, Siva Chandra finally provided their actual rationale for wanting to do it and it's here. It seems like a lot of good ideas but I still don't really understand why a full rewrite is necessary (read: it's not, it's them going uhhh we're google of course we'll do it better) instead of larger contributions to e.g. musl.
|
|
#
?
Jun 27, 2019 13:49
|
|
|
Phobeste posted:Well, Siva Chandra finally provided their actual rationale for wanting to do it and it's here. It seems like a lot of good ideas but I still don't really understand why a full rewrite is necessary (read: it's not, it's them going uhhh we're google of course we'll do it better) instead of larger contributions to e.g. musl. Watch them start it out, get buy-in from a couple of companies and developers, then pull it from under them and leave them in the lurch.
|
|
#
?
Jun 27, 2019 14:07
|
|
|
Absurd Alhazred posted:Watch them start it out, get buy-in from a couple of companies and developers, then pull it from under them and leave them in the lurch. 2019: "We're building the llvm libc." 2021: "We're introducing our own compiler which will come with its own libc. Incidentally, we're deprecating the llvm libc." 2023: "The Google c compiler project is being shut down."
|
|
#
?
Jun 27, 2019 14:26
|
|
|
Phobeste posted:Well, Siva Chandra finally provided their actual rationale for wanting to do it and it's here. It seems like a lot of good ideas but I still don't really understand why a full rewrite is necessary (read: it's not, it's them going uhhh we're google of course we'll do it better) instead of larger contributions to e.g. musl. I'm still concerned about their closing sentence: quote:All this does not mean we want to implement everything from scratch. If someone has implementations for parts of the libc ready, and would like to contribute to this project under the LLVM license, we will certainly welcome it.
|
|
#
?
Jun 27, 2019 16:55
|
|
|
So what's stopping Google from creating their own snowflake version of libc for their own use instead of trying to force it as a new standard? It looks like recently, Google's run out of ideas for actual products, so they're looking at things that are already in use and entrenched, and then giving them the NIH treatment, but entirely from their own self-serving perspective, as if all those other systems already in place don't matter at all. It would be a different story if they proposed rebuilding some legacy technology from scratch but remaining interoperable with the existing legacy systems out there, or if they proposed rebuilding some legacy technology without backwards compatibility constraints, but in a way that would benefit everyone. But they seem extremely unashamed about proposing incompatible "replacements" that benefits nobody but themselves, with the expectation that things will go their way purely because they're Google (or that everyone else doesn't matter, because they're not Google). 
|
|
#
?
Jun 27, 2019 20:31
|
|
|
beuges posted:So what's stopping Google from creating their own snowflake version of libc for their own use instead of trying to force it as a new standard? That's what they're doing though? And they explicitly aren't even touching multiple platforms for it?
|
|
#
?
Jun 27, 2019 20:34
|
|
|
fishmech posted:That's what they're doing though? And they explicitly aren't even touching multiple platforms for it? I dunno, it sounded like they're at least wanting to make this into something clang would adopt. And by encouraging ~the community~ to contribute the work, they're at least trying to get it entrenched outside of Google as well.
|
|
#
?
Jun 27, 2019 20:42
|
|
|
They'd like it to be in the LLVM project, since LLVM does not currently provide a libc. Presumably they would push it as part of a complete LLVM toolchain for targets that are open to changing their libc and want totally static binaries, which in practice just means weird embedded environments; on the other hand, that would require portability, which they seem to have marginal interest in even planning for.
|
|
#
?
Jun 27, 2019 20:52
|
|
|
Yeah that guy didn’t seem to respond well to “uh you may only want support for Linux x86-64 but if you want this to ever be cross platform and abi you need to plan that from the start”
|
|
#
?
Jun 27, 2019 20:54
|
|
|
rjmccall posted:They'd like it to be in the LLVM project, since LLVM does not currently provide a libc. Presumably they would push it as part of a complete LLVM toolchain for targets that are open to changing their libc and want totally static binaries, which in practice just means weird embedded environments; on the other hand, that would require portability, which they seem to have marginal interest in even planning for. Don't the weird embedded environments already use newlib?
|
|
#
?
Jun 27, 2019 21:03
|
|
|
I'm not an expert, but I feel completely confident in saying that each and every one does its own special snowflake thing.
|
|
#
?
Jun 27, 2019 21:40
|
|
|
rjmccall posted:They'd like it to be in the LLVM project, since LLVM does not currently provide a libc. Presumably they would push it as part of a complete LLVM toolchain for targets that are open to changing their libc and want totally static binaries, which in practice just means weird embedded environments; on the other hand, that would require portability, which they seem to have marginal interest in even planning for. I am guessing the intended case here is more "servers running in containers".
|
|
#
?
Jun 27, 2019 21:53
|
|
|
rjmccall posted:I'm not an expert, but I feel completely confident in saying that each and every one does its own special snowflake thing. Over here it's "halfassed implementation of the functions people happened to need" Turns out printf is a lot easier to write if you only support plain %d, %x and %s
|
|
#
?
Jun 27, 2019 22:00
|
|
|
|
| # ? Jun 7, 2024 21:31 |
|
|
Qwertycoatl posted:Over here it's "halfassed implementation of the functions people happened to need" Yep! I remember writing one of those in my kernel project in college. I couldn't properly test how well my kernel handled a forkbomb because the userspace libc the TAs gave us was so huge relative to the memory capacity of the VM, so I hacked up a tiny libc so that each process would only need a few kilobytes of memory. Found a few bugs that way, too.
|
|
#
?
Jun 27, 2019 22:08
|
|