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

21–30 of 340 posts

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

#21

Post by tredre3 »

AlienRobot wrote: post #16
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…

>The problem now doubles with the introduction of UTF-8. Your string size is in bytes and you need to track characters separately. That isn't really a problem. The problem with null-terminated strings is specifically what happens when you reach the end of the allocated array and there ISN'T a NULL character. Every string function is designed to keep going until it finds the NULL character, so if a hacker gets rid of…

> No other data structure works like this.

In C most data structures work like this, you keep going until you find NUL (character) or NULL (pointer). E.g. Strings, array of pointers, linked lists, etc. Of course you can add length to most of those, but it isn't the canonical/traditional way of doing things.

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

#22

Post by bellowsgulch »

dietr1ch wrote: post #9
mrlonglong wrote: post #2

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

I think it was NULL itself. It was a long way until we realised we don't want invalid values and could use the type system to help us use special values safely.

Compared to scripting languages with actual tagged types, C doesn't really have a type system, and that's readily apparent to anyone who has written C in the last 43 years and debugged a program written in it.

C pretends types exist with you, but once bytes hit the road, it's all real-life and segmentation faults.

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

#23

Post by UqWBcuFx6NV4r »

jkercher wrote: post #13
dietr1ch wrote: post #9

Earlier quoted context omitted.

I think it was NULL itself. It was a long way until we realised we don't want invalid values and could use the type system to help us use special values safely.

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]

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

#24

Post by kps »

egorfine wrote: post #6
PlunderBunny wrote: post #5

I worked on a Win32 app that used space-padded strings, i.e. the destination string was padded with spaces, but there was still a null on the last byte. You had to use special versions of the string functions for length, copy etc. I’m not sure why this was - the source base was so old it might have had its origins in Pascal struct behaviour.

I think this behavior has its roots in COBOL, not pascal.

Which has its roots in punch cards, where pre-computer hardware operated on fixed-sized fields and an unpunched column is equivalent to a space.

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

#25

Post by naturalmovement »

BoingBoomTschak wrote: post #20
naturalmovement wrote: post #18

A reminder that we've had strlcpy [1] for ~ 30 years but it was never accepted into the Linux world because of typical petty open source bullshit. This is why we can't have nice things. [1] https://man.openbsd.org/strlcpy

Actually, glibc 2.38 has it.

Wow it only took them 26 years to import a 30 line C function, a third of which is comments?

I should have sent them a nice fruit basket to commemorate the occasion.

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

#26

Post by senfiaj »

I wonder, why not use a string buffer paired with its length? For example, maybe use struct that has char pointer, and 2 ints (occupied length + total buffer length). Almost like c++'s std::string. This null terminator thing really sucks, it's potentially insecure and often unperformant.

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

#27

Post by bsder »

mrlonglong wrote: post #2

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

Zero terminated string is a special case of sentinel value termination.

And sentinel value terminations make a lot of sense when you have punch cards and fixed length records that you need to carve into pieces.

Nobody expected any decisions they were making in the 1960s and 1970s to have any bearing on computing a half-century later. They all expected to have their mistakes long papered over by smarter people at some point.

But we ALL make the mistake of underestimating inertia.

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

#28

Post by estebank »

msla wrote: post #15
mrlonglong wrote: post #2

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

In addition to having to pick a size for the length counter and then, later, having to differentiate between lengths in bytes, codepoints, and glyphs, you can't subdivide a Pascal string using pointer arithmetic. To pass just the end of a string into a function, you have to either copy the tail of one Pascal-style string to another with a smaller size value, or your string has to be a struct with an integer and a poi…

The third option is to have a variable width length: the top most bit signals whether the next byte corresponds to the length or to the start of the string.

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

#29

Post by ericbarrett »

naturalmovement wrote: post #18

A reminder that we've had strlcpy [1] for ~ 30 years but it was never accepted into the Linux world because of typical petty open source bullshit. This is why we can't have nice things. [1] https://man.openbsd.org/strlcpy

The Linux kernel had strlcpy over 20 years ago. It was removed in favor of strscpy because the latter was judged a better interface. Here's a 2022 article: https://lwn.net/Articles/905777/

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

#30

Post by bvrmn »

jkercher wrote: post #13
dietr1ch wrote: post #9

Earlier quoted context omitted.

I think it was NULL itself. It was a long way until we realised we don't want invalid values and could use the type system to help us use special values safely.

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…

NULL as a concept is fine. Inability to declare something as non-null is not.

There is a huge gap between developer expectation "it's pointing at something known" and hard reality confirmed by zillions of CVE. That's the reason optionality is prevalent in modern languages and type checkers (python, typescript), nowdays even Java has sane non-nullable types.

Post reply on HN