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

251–260 of 340 posts

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

#251

Post by darkr »

BobbyTables2 wrote: post #111
mrlonglong wrote: post #2

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

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 a weakly typed language. It’s statically typed, which is a different thing

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

#252

Post by pitched »

imtringued wrote: post #182
tialaramex wrote: post #156

Earlier quoted context omitted.

"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 f…

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.

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

#253

Post by flohofwoe »

skywhopper wrote: post #226
flohofwoe wrote: post #199

Earlier quoted context omitted.

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

What programming languages try to guess line endings? Or are even aware of them?

Ok, technically not the programming languages, but their stdlibs. On MSVC at least, opening a file in text mode via fopen will translate CRLF into LF on read, and LF into CRLF on write, which has been a neverending source of confusion since at least the 1990s.

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

#254

Post by Parodper »

jerf wrote: post #52
chiph wrote: post #39

Earlier quoted context omitted.

Pascal did/does this, but eventually someone wants a string longer than the size portion can handle. Or wants the number of characters not the number of bytes.

I wasn't a programmer in these days, so I don't know if there's some other major concern that would kill this, but I sometimes wonder about whether we could have / should have used variable-length integers. That is, something like, 0-127 byte strings get their length prefixed, 128 - 16383 get two bytes of prefix, and the probably-rare 16384 - 2097151 strings would end up with three, though proportionally by that poin…

You could start the encoding with two bytes, so that if the most significant bit of the first byte is 0, the length is that byte plus another. That gives you 32KiB strings with just a byte more. Short strings might suffer, but I think the overhead is reasonable.

The next level (110x xxxx) would give you 8MiB strings, which are going to be fine for most things.

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

#255

Post by hahn-kev »

thiht wrote: post #229

> In place of strncpy, Linux kernel code should use strscpy() for NUL terminated destinations, strscpy_pad() for NUl-terminated destinations with zero-padding, strtomem_pad() for non-NUL-terminated fixed-width fields, memcpy_and_pad() for bounded copies with explicit padding, or memcpy() for known-length memory copies What a nightmare, does it have to be so convoluted?

Couldn't they at least give them better names?

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

#256

Post by atherton94027 »

Parodper wrote: post #245
lelanthran wrote: post #202

Earlier quoted context omitted.

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.

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

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

#257

Post by pwg »

dare944 wrote: post #90
themafia wrote: post #10

Earlier quoted context omitted.

> Pascal style strings were much safer. The limitations were brutal. Initially you could only have 255 bytes in a string. The length of a string and the size of the allocation are now separate and you may need to think about that unused memory in your design. The problem now doubles with the introduction of UTF-8. Your string size is in bytes and you need to track characters separately. If you want to create an array…

> You can spread propaganda and poorly sourced zeitgeist and be among friends but if you try to have a genuine conversation about programming languages you are made to be unwelcome immediately. Indeed. And the ignorance of computing history in this discussion is particularly disturbing. The context of this particular thread is "zero terminated string is ... computing's biggest mistake". This completely ignores the si…

> This completely ignores the situation on the ground when C was developed.

A great many of those replying are many years short of having experienced anything like "the situation on the ground when C was developed". They simply have never known a day without hundreds of gigabytes or more of disk storage and 8G or more of RAM available for user processes after the OS consumes what it needs for its own work. They are "ignoring" because they simply have no basis for understanding.

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

#258

Post by brewmarche »

rswail wrote: post #160

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

Now with Unicode we actually have even more:

NL Next line (from EBCDIC?)

LS Line separator (invented by Unicode)

PS Paragraph separator (same)

The Unicode standard says that in addition to CR, LF, CRLF and the above, vertical tabs and form feeds should also be treated as line separators.

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

#259

Post by badsectoracula »

layer8 wrote: post #171
mrlonglong wrote: post #2

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

There is a middle ground that Visual Basic (and then COM) took, with the BSTR type: It’s still a pointer to a zero-terminated char array, but there is a length field immediately preceding the first pointed-to byte. This is still compatible with a C string (assuming no embedded null characters), but BSTR-typed functions can take advantage of the length value.

FWIW pretty much all Pascals since the 90s use a similar approach.

In Free Pascal for instance, strings are pointers to the first character with a header in a "negative address" containing information about the length, reference count (strings are reference counted and use copy-on-write to avoid passing around copies all the time) and codepage (FP can convert strings between different encodings "transparently").

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

#260

Post by badsectoracula »

bc_programming wrote: post #151
jxbdbd wrote: post #138

Earlier quoted context omitted.

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?

Free Pascal strings (and i assume Delphi as they are sometimes compatible) are pointers to the first character of a null terminated string with a header in a negative offset before the first character indicating the string's length, reference count and codebase.

AFAIK a "Pascal string" is basically another way to say "length-prefixed string" (as opposed to null terminated string) and Free Pascal (and Delphi) are like that (and they're Pascal dialects too, so their strings are literally Pascal strings :-P).

Post reply on HN