Earlier quoted context omitted.
Borland's PASCAL did it on the IBM PC. And which modern C compiler fits into 64KB? Even TCC needs 100KB. But that's beside the point. No machine of the last 36 (I'll push my chances, 40) years needs to fit a compiler in 64KB.
Pascal had pointers? They could be `nil` too https://www.freepascal.org/docs-html/ref/refse15.html
Linux eliminates the strncpy API after six years of work, 360 patches
281–290 of 340 posts
Re: Linux eliminates the strncpy API after six years of work, 360 patches
#282Earlier quoted context omitted.
Right. I am not claiming Claude Code creates perfect software. I am refuting your claim that using it would be cost prohibitive. I took the 10 most difficult patches from the git history - the ones that took the most back-and-forth to fix. I asked Claude to write them. Would you like to see the work? If you believe a human performs better at finding downstream effects - you need to prove that. I see no reason why it…
> If you believe a human performs better at finding downstream effects Once gain, you are not reading what is being said - no one made that claim! No claim was made in fact: it was a refutation. Specifically, the refutation is "this is why it took so many years".
You did not literally make that claim but your cost argument hinges on it.
Without it, then Claude does about the same as a human and only costs $100.
Apparently I'm reading your comments more thoroughly than you are.
Re: Linux eliminates the strncpy API after six years of work, 360 patches
#283Earlier quoted context omitted.
Would you even know? Serious question. The volume of code the models can produce, the subtle ways these bugs can manifest (or even only manifest when under attack), it seems like they would be easy to overlook.
I have a habit of getting GPT 5.5 to review everything Opus writes for me, and vice versa. The model in the reviewer role frequently finds things I overlooked myself. Occasionally in parts of the code I wrote. No modern LLM has found any buffer overflow bugs in parts of my code that originated from another LLM. Again, though, they have found one or two that were my fault.
Re: Linux eliminates the strncpy API after six years of work, 360 patches
#284Earlier quoted context omitted.
Line feed resetting position really makes no sense. It should just continue text from where the cursor was but on next line. Like staircase. You need CR to go back to start.
Yes, if you're talking to a terminal. But an in-disk file doesn't have a carriage to return.
Re: Linux eliminates the strncpy API after six years of work, 360 patches
#285Earlier quoted context omitted.
UNIX's LF precedes them by at least half a decade, probably more.
CRLR is Baudot, predating UNIX by what, a century ?
The fact that both Apple's and CP/M codes came out roughly at the same time, both on microcomputers, shows that it was probably just a design decision.
Re: Linux eliminates the strncpy API after six years of work, 360 patches
#286the zero terminated string is I think is computing's biggest mistake. Pascal style strings were much safer.
Re: Linux eliminates the strncpy API after six years of work, 360 patches
#287Re: Linux eliminates the strncpy API after six years of work, 360 patches
#288Re: Linux eliminates the strncpy API after six years of work, 360 patches
#289Earlier quoted context omitted.
> 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…
Re: Linux eliminates the strncpy API after six years of work, 360 patches
#290Earlier quoted context omitted.
How are you going to build sum types in a way where you can interact with assembly or machine code? The CPU doesn't know about that stuff
Sum types map down to reading a tag and doing a comparison against fixed values. I don't know what to tell you, but you're clearly not cut out to be a software developer in either machine code, assembly or C or any other language if you don't understand something this basic.