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

151–160 of 340 posts

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

#151

Post by bc_programming »

jxbdbd wrote: post #138
Conscat wrote: post #135

Earlier quoted context omitted.

Clang and GCC both let you use Pascal strings in C if you would like (with `\p`). But Pascal strings aren't that useful today because the maximum length is too short.

Why would a pascal string be any shorter than a C string? A C string is one pointer reaching all of memory, a Pascal string is two pointers reaching all of memory

A pascal string is a single byte with the length, followed by the data.

Some implementations use more bytes for the length data, such as Delphi which changed over to a 4 byte prefix length, though those aren't technically Pascal strings anymore. I can't find anything about a Pascal string being two pointers?

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

#152

Post by lelanthran »

mrlonglong wrote: post #2

the zero terminated string is I think is computing's biggest mistake. Pascal style strings were much safer.

> the zero terminated string is I think is computing's biggest mistake.

No. They had trade-offs to make, and sentinel-based sequences are a needed thing, even outside of strings.

The mistake was that ISAs never looked at what HLL needed, then add the necessary instructions (I posted more about this below).

Even NULL is not a big mistake, when looked at in context of the time in which it was developed.

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

#153

Post by JdeBP »

dare944 wrote: post #98
jibal wrote: post #75

The purpose of strncpy, which was originally part of the UNIX kernel code, was to copy file names to and from directory entries that consisted of a 2 byte inode number and a 14 byte zero-padded but not zero-terminated name field. I started warning my colleagues against using it the moment I saw it for the first time about 50 years ago.

strncpy appears somewhere around the Unix v7 time frame, however only as function in the standard C library. It is not used in the v7 kernel itself.

In Unix Seventh Edition, ls and others read directory entries with fread() and parsed the struct direct themselves in application-mode code. The C library and application mode matter, here.

On the gripping hand, there is no strncpy in the Spinellis 7th Edition source code; 4.2BSD was using strncpy() inside readdir() in 1982, though.

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

#154

Post by lelanthran »

pdimitar wrote: post #65
atherton94027 wrote: post #49

Earlier quoted context omitted.

Genuinely curious, how would you handle cases where a value is unset without NULL? This is a legitimate case that happens a lot in eg data modeling

Sum types, of course.

How do you expect to use sum types in assembly? Remember where C came from and why it was designed the way it was.

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

#155

Post by Tempest1981 »

cm2187 wrote: post #118
edoceo wrote: post #113

Earlier 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…

I wonder if an early built-in string class would have been 8-bit or 16-bit UCS-2? Would have been hard to stomach 16-bit storage and performance.

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

#156

Post by tialaramex »

zeroonetwothree wrote: post #128
BobbyTables2 wrote: post #111

Earlier quoted context omitted.

Partly agree but there would have been squabbling on the data type of the size, unless it was variable length. The latter would have had other issues too. For a while, 16bit would probably have seemed too extravagant. Now 32bit would probably seem too small. For a “strongly typed” language, C is pretty damn loose where would have mattered.

C is not really strongly typed.

"Strongly typed but weakly checked"

It turns out that the machine is much better at the sort of boring mechanical tasks where thoroughness counts and imagination doesn't and so languages which do more, and more, and more checking pay off very well. Rust's borrowck is the obvious first thought today but say WUFFS will check that you've proved certain key properties, WUFFS doesn't need to insert runtime bounds checks for example because you've proved, before the code would compile, that you don't have any bounds misses. You might have proved it by writing bounds checks yourself of course, or likely you have an inherent mathematical rationale for why your algorithm has no misses, but either way the compiler checked your work.

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

#157

Post by fragmede »

pjc50 wrote: post #133
fragmede wrote: post #36

Earlier quoted context omitted.

compared to Von Newman versus Harvard architecture for LLMs? I think that's a far bigger mistake.

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.

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

#158

Post by jibal »

JdeBP wrote: post #153
dare944 wrote: post #98

Earlier quoted context omitted.

strncpy appears somewhere around the Unix v7 time frame, however only as function in the standard C library. It is not used in the v7 kernel itself.

In Unix Seventh Edition, ls and others read directory entries with fread() and parsed the struct direct themselves in application-mode code. The C library and application mode matter, here. On the gripping hand, there is no strncpy in the Spinellis 7th Edition source code; 4.2BSD was using strncpy() inside readdir() in 1982, though.

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.

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

#159

Post by jibal »

JdeBP wrote: post #153
dare944 wrote: post #98

Earlier quoted context omitted.

strncpy appears somewhere around the Unix v7 time frame, however only as function in the standard C library. It is not used in the v7 kernel itself.

In Unix Seventh Edition, ls and others read directory entries with fread() and parsed the struct direct themselves in application-mode code. The C library and application mode matter, here. On the gripping hand, there is no strncpy in the Spinellis 7th Edition source code; 4.2BSD was using strncpy() inside readdir() in 1982, though.

Here it is in 2.9BSD: https://www.tuhs.org/cgi-bin/utree.pl?file=2.9BSD/usr/src/uc...

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

#160

Post by rswail »

Things 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 codes.

Post reply on HN