Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux eliminates the strncpy API after six years of work, 360 patches

phoronix.com

Post reply on HN
Print view View original

291–300 of 340 posts

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#291

Post by jibal »

dare944 wrote: post #248
jibal wrote: post #158

Earlier quoted context omitted.

login used it, but not for directory entries: https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/lo... The code, but not the function, occurred in multiple places in the V6 kernel and userland.

> The code, but not the function, occurred in multiple places in the V6 kernel and userland. Yep. The code is essential given the design of the direct structure, which harkens back to the fixed-width data fields of punched cards.

It doesn't have anything to do with punch cards, it's to pack as many elements as possible into the very small amounts of memory on PDP-11s. A 16 byte directory structure (which divides evenly into a disk sector) with a 2 byte inode number and an up to 14 byte name is a memory-optimized structure, and memory optimization drove everything on UNIX. (I've been programming since 1965, used punch cards for a decade, was a UNIX V6/V7/PWB kernel and userland developer for a different decade).

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#292

Post by CamperBob2 »

bigstrat2003 wrote: post #283
CamperBob2 wrote: post #72

Earlier quoted context omitted.

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.

Having one clanker verify the output of another has minimal, almost non-existent, persuasive value as evidence.

Hopefully you're close enough to retirement age that it's a moot point for you.

If not, you're headed for a bad time, a major attitude adjustment, or (most likely) both.

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#293

Post by amomchilov »

fragmede wrote: post #157
pjc50 wrote: post #133

Earlier quoted context omitted.

Neumann, and .. what? In what way?

Prompt injection only works because there isn't two streams of input to give to the LLM. Von Neumann being the architecture with a single shared memory for both data and instructions. If there were a clean way for the LLM model to distinguish between system messages vs user messages, we wouldn't have that problem.

I don’t know how you could keep the two isolated, without drastically dropping up the utility of LLMs.

Part of their wonder is how they can behave differently depending on the data they’re working with. We like that feature when the data is the “good stuff” (docs, compiler messages, etc.), but how you tell that apart from “bad stuff” (prompt injection on official-seeming pages).

We basically expose LLMs to the same social-engineering vulnerabilities that humans have.

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#294

Post by parineum »

flohofwoe wrote: post #212
rswail wrote: post #209

Earlier quoted context omitted.

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.

> Apple used CR Apple hasn't been using CR since the release of OSX (26 years ago). Microsoft could have made the switch at any time too (just as they could have switched to UTF-8 as universal text encoding on Windows), they just choose not to. In the end it's not the job of programming languages to clean up Microsoft's mess ;)

> In the end it's not the job of programming languages to clean up Microsoft's mess ;)

Why is it Microsoft's fault? They just stayed on their legacy implementation, Linux and Apple chose to move from the legacy implementation to another legacy implementation. That seems dumb.

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#295

Post by kps »

ryandrake wrote: post #284
Parodper wrote: post #236

Earlier quoted context omitted.

Yes, if you're talking to a terminal. But an in-disk file doesn't have a carriage to return.

Modern computer text output devices don’t have a “carriage” or a “feed” mechanism. I’d argue both CR and LF are legacy, anachronistic characters whose purpose was too device specific to make sense as a text encoding.

Sure, there's a text encoding part and an equipment control part that puts the CII in ASCII.

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#296

Post by bigstrat2003 »

larodi wrote: post #3

Wonder when is someone going to brave and fork the linux kernel and try to ffwd it with automatic programming.

Going fast is only good if you're going the right direction. And with LLMs, more often than not you're going off a cliff.

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#297

Post by jkercher »

UqWBcuFx6NV4r wrote: post #23
jkercher wrote: post #13

Earlier quoted context omitted.

Meh, I think NULL is fine in C. It's an extra, valid state to represent pointers at no cost. Unlike the more hand holdy languages, it's quite rare for a pointer in C to have the ability to be NULL since, more often than not, it's pointing at something known. It's actually quite rare to see NULL checks unless it's API code or something like that. I can see this being more of a problem in a managed language where anyth…

[flagged]

I don't know man. It's just zero. Dereferencing it just crashes your program (assuming an operating system). This kind of just reads like a fear of pointers. Corrupted/out-of-range pointers are, at least, a real problem.

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#298

Post by JdeBP »

Parodper wrote: post #214
rswail wrote: post #209

Earlier quoted context omitted.

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.

UNIX's LF precedes them by at least half a decade, probably more.

rswail said ASCII, which definitely pre-dated Unix, not the other way around. And there was some to and fro about the equivalence of LineFeed and NewLine in the 1960s.

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#299

Post by tialaramex »

pitched wrote: post #252
imtringued wrote: post #182

Earlier quoted context omitted.

This is something that has irritated me for a long time. Bounds checks and sized arrays and strings are mechanically very easy to perform by a machine. These are highly automated tasks. There are some extreme cases where they ruin performance, but in the vast majority of cases they don't matter. If you look at the type of tasks that cannot be automated, if going from no to full automation required an efficiency loss…

Anyone willing to accept an efficiency loss is already using an interpreted language and doesn’t have this class of problems.

> Anyone willing to accept an efficiency loss is already using an interpreted language and doesn’t have this class of problems.

Linux already takes several of these "efficiency loss" choices in C. The insistence that "actually I never make this mistake" has to be the surest sign that you're not talking to a real engineer across our whole industry. I associate it most with Bjarne Stroustrup, a man who has written a lot of books and papers but no notable software since his "cfront" C++ transpiler decades ago.

And besides all that, WUFFS isn't even taking an "efficiency loss" - remember it isn't emitting bounds checks it just checks that you proved you don't have bounds misses.

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#300

Post by robocat »

t-3 wrote: post #233
Conscat wrote: post #149

Earlier quoted context omitted.

A Pascal string has a leading length byte. Because that is one byte, the text can't exceed 255 characters.

For modern hardware, a 64-bit length is more practical though - no alignment issues. It seems to me that Pascal's specifying a single byte prefix was a language design "mistake" of the same type as NULL termination, putting hardware considerations into the language definition. Very practical for machines of the time, but not necessarily the best choice in hindsight.

> single byte prefix was a language design "mistake"

Easy to say in hindsight.

It was an optimisation made back when every single byte mattered because you might have some kilobytes of memory and a 6502 CPU (where you strongly avoided using 16 bit pointers or arithmetic - because your program would be too bloated otherwise).

At the time Pascal was used, a whole byte for each string was seen as a waste - so fixed length strings were often used instead.

Post reply on HN