I wonder what is the difficulty in rewriting strncpy uses that makes it take six years? Was it widespread? Or was it more of a long going effort, where it was only changed if there were some changes in the same file? Or is there some other thing that makes it difficult?
Linux eliminates the strncpy API after six years of work, 360 patches
201–210 of 340 posts
Re: Linux eliminates the strncpy API after six years of work, 360 patches
#202Earlier quoted context omitted.
> You asked how sum types work in assembly. No, I didn't - I asked how sum types were supposed to work in an era of 64KB memory systems.
They don't need extra memory in Rust for the case of nullable pointers. The boring cases require an enum tag in C too. By bringing up the one thing that doesn't matter, your argument becomes purely ideological.
You're missing the point - give me a Rust compiler that can run and compile in 64KB memory, then you'll understand that the language C was constrained not just by what the output is running on, but by what the machines of the time could actually handle during compilation.
Re: Linux eliminates the strncpy API after six years of work, 360 patches
#203Earlier quoted context omitted.
What's a way they could get a strong data type here? Wouldn't that also require a large refactor of the code around strncpy to use the type and its functions?
Today yes, but 40 years ago someone made the decision that a string was a char array and that every string manipulation going forward would require manipulating arrays. Talking about costly decisions. It’s actually interesting to compare the pain and suffering of switching to a string datatype in the 80s (refactoring the limited code base then) vs the next 40 years of unnecessary boiler plate syntax and bugs for not…
> Today yes, but 40 years ago someone made the decision that a string was a char array and that every string manipulation going forward would require manipulating arrays
That's not a bad thing, Common Lisp does the same and it Just Werks. The real problem is the more general "array to pointer decay", not arrays, really.
Re: Linux eliminates the strncpy API after six years of work, 360 patches
#204Earlier quoted context omitted.
Linux doesn't exist in the 1980s, Linus started this work in the 1990s. But yes, the string slice type should have existed in C89 and it's very obvious from here that not having something of this sort - maybe what Rust would call &[u8] the reference to a slice of bytes - was a big problem for C. The correct way to represent this is what's called a "fat pointer". A pair of values, one is a conventional "thin" pointer…
I'd be curious to see how much CPU time is wasted on looking for a null every time strlen is called. The extra length integer is probably insignificant compared to that.
It is very expensive if you repeatedly measure and forget the length, this is presumably some of the price in Google's problem where some engineers wanted to use 0-terminated char* as the type of a string but others wanted C++ std::string and so the software ends up measuring how long the string is, allocating and copying, then immediately forgetting that length, only to once again measure how long it is, allocate and copy again.
That's a language design defect, C++ got its string slice reference (named std::string_view) only in 2017, years after Rust 1.0 shipped this as a core language feature, even though C++ is decades older.
On the other hand I can well believe on a 1970s computer where you'd be lucky to have 64kB of RAM the trade looks very different, I just think that by C89 it should have been fixed.
Re: Linux eliminates the strncpy API after six years of work, 360 patches
#205Earlier quoted context omitted.
C was specifically developed to allow Unix to be ported. It was a systems programming language and the first well known/successful one. There was BCPL and then B before that, which is why the language is called "C". Pascal was considered a teaching language, along with "Algorithms + Data Structures = Programs" by Wirth etc. The UCSD P-system was one of the first "IDEs" and used Pascal and a bytecode interpreter of th…
Successful systems languages trace back all the way to JOVIAL in 1958. You missed quite a few between JOVIAL, and C being adopted outside Bell Labs. Modula-2 was as widely available as C was outside UNIX and universities with access to UNIX source code. It took a while for proper C to actually be "used for everything else", until the early 1990s actually, and by then anyone sensible would be much better with Typescri…
I dunno, I was starting my career around 1980-81, and the choices were 6502/6509/Z80/8088 asm, C, UCSD-Pascal, and BASIC at the micro level, C/asm was the rule for RT-11/RSX-11 and then the VAX OSs at the "minicomputer" level.
I had a friend that tried to get everyone using Modula-2 but the "ecosystem" wasn't as great around the uni/ex-uni environments where I was.
C was pretty entrenched by the end of the 1980s, although I did use a weird embedded Pascal that was on HP-UX cross-compiling for Z80/8086 at the end of the decade, but they were the exception rather than the rule.
C++ was just a preprocessor for C and a "better C" at the time, people were still bitching about header files with function type signatures of "ANSI C" vs "good old-fashioned K&R".
We also tied onions to our belts...
Re: Linux eliminates the strncpy API after six years of work, 360 patches
#206Things that have bugged me for 40 years... * NUL terminated strings (and now, non UTF-8 encoded strings on input/output) * Using LF or CR or CRLF as line terminators, and pipe/comma-delimited fields when there were other unambiguous ASCII characters that could have been used (eg, GS, FS, RS) that would have made the encoding/decoding of line termination an I/O thing keeping HT/VT/CR/LF/FF as literally print related c…
I did a project to translate data framed in the ASCII field/record separator characters and it was gloriously easy. All the ugly escaping considerations with comma-delimited data went away and it became much easier.
Re: Linux eliminates the strncpy API after six years of work, 360 patches
#207I have in the past made fun of the Linux kernel devs, supposedly some of the best C developers in the world, for not knowing how to make stringbuffer and stringview types, but to be fair to them we didn't have the consensus we have today on the topic. You know who did have the right idea though? Dennis Ritchie, who proposed a fat pointer type for C all the way back in 1990. Would have made for a perfect addition to C…
> But we did get _Generic and VLAs! Party hard. VLA has been demoted to an optional feature in C11 (good). IMHO the current main problem is that the C stdlib is stuck in the K&R era and the stdlib APIs haven't even been updated to the language features added in C99 (e.g. make use of struct args and return values). A range struct (ptr/size pair) in the stdlib and new or updated string functions to use such ranges woul…
> IMHO the current main problem is that the C stdlib is stuck in the K&R era and the stdlib APIs haven't even been updated to the language features added in C99 (e.g. make use of struct args and return values).
C++ has the same issue (only with more chaos and bloat). They add some new good idea (like optional) but don't update the rest of the standard library to make use of it. And they can't really, without breaking backwards compatibility.
I think looking at the edition system in Rust could be useful for C and C++ to start to solve this. Something like "If this source file has this pragma in it, compile that code with a new edition". It would have to be granular, per expression really, to handle macros (which is how it works in Rust too). What would it change in C/C++? Name resolution, you could get a different set of resolvable overloads, depending on which edition is active in the caller context. Not unlike an enable_if.
The same would work in C: depending on the caller edition, expose function signatures.
Re: Linux eliminates the strncpy API after six years of work, 360 patches
#208Earlier quoted context omitted.
> If the hardware had instructions for sentinel values, things would be easier (Like how DOS calls used '$' termination for strings) and safer. A zero is a sentinel value and is catered to by all ISAs. Why would using a "$" be any easier/safer than a NUL?
> A zero is a sentinel value and is catered to by all ISAs. > Why would using a "$" be any easier/safer than a NUL? I didn't say it had to be '$'; I specifically said that the sentinel would be loaded into a register. In that case it could be anything, including zero (for the snippet you posted), or INT_MAX if the code iterated across an array of integers, etc. By having rep/mov variants that use sentinels, a lot of…
Except that nearly all ISAs treat zero as a special value, with a Z-flag or equivalent for the last ALU result, and conditional branches around that result.
PDP-11s, 68Ks, nearly all ISAs that I know about treat zero as special.
It falls naturally out of the ALU operations.
So why would people writing assembler code use another value unless they had to?
Re: Linux eliminates the strncpy API after six years of work, 360 patches
#209Things that have bugged me for 40 years... * NUL terminated strings (and now, non UTF-8 encoded strings on input/output) * Using LF or CR or CRLF as line terminators, and pipe/comma-delimited fields when there were other unambiguous ASCII characters that could have been used (eg, GS, FS, RS) that would have made the encoding/decoding of line termination an I/O thing keeping HT/VT/CR/LF/FF as literally print related c…
> non UTF-8 encoded strings on input/output UTF-8 on stdin/stdout works perfectly fine (unless you are on Windows of course, which is stuck in in the early 90s when it comes to international text encoding). > Using LF or CR or CRLF as line terminators This is also an operating system convention, and it would be better if programming languages wouldn't try to "guess" the correct line endings, since this causes more pr…
No, it was an Apple, Unix, and Microsoft problem.
Unix used LF, Apple used CR, Microsoft used CRLF.
They are all ASCII carriage movement codes, which is about driving the paper feed and print head of an ASR-33 or equivalent.
So they all made the "wrong" decision about what to store in a file.
They just chose different wrong characters.
Re: Linux eliminates the strncpy API after six years of work, 360 patches
#210Earlier quoted context omitted.
Successful systems languages trace back all the way to JOVIAL in 1958. You missed quite a few between JOVIAL, and C being adopted outside Bell Labs. Modula-2 was as widely available as C was outside UNIX and universities with access to UNIX source code. It took a while for proper C to actually be "used for everything else", until the early 1990s actually, and by then anyone sensible would be much better with Typescri…
> Typescript for C You mean "C with Classes", later to be replaced by "C++" (Stroustrup pick this as favorite from a list of candidate names he crowdsourced) as implemented by Cfront.
I preferred "P" because of the BCPL ancestor.
If BCPL begat "B" and "B" begat "C", then "C" should have begatten "P".
Not sure if begatten is a word :)