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

61–70 of 340 posts

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

#61

Post by bnolsen »

lambdaone wrote: post #47
XorNot wrote: post #37

Earlier quoted context omitted.

The problem with let's get rid of NULL is that it's a real, required state. The vast majority of computing is actually not binary: any real input generally has at least 3 possible states: not set, true and false. In practice really 4 because "indeterminate" is a reasonable error condition you'd like to know about. And it keeps increasing anyway: e.g. not set has subcategories: not set due to lack of user input, not s…

What you are describing is option types, which are an entirely valid and very useful construct that helps make programs more rather than less reliable. But you need proper language type system support and compile-time enforcement to make it work, and C does neither of those.

C++ and rust make these optionals ugly. Zig does it right. Zig also forbids null pointers and requires use of optionals.

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

#62

Post by clnhlzmn »

atherton94027 wrote: post #49
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.

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

The way we do it in modern languages with things like std::optional and even that is not the best example.

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

#63

Post by WalterBright »

senfiaj wrote: post #26

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.

Wonder no longer!

https://dlang.org/spec/arrays.html#dynamic-arrays

and

https://dlang.org/spec/arrays.html#strings

and for C:

https://digitalmars.com/articles/C-biggest-mistake.html

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

#64

Post by AnimalMuppet »

deathanatos wrote: post #57
AnimalMuppet wrote: post #31

Earlier quoted context omitted.

AGI might. AI? No way. See, AI was trained on existing data - on all that existing C code out there (sure, and also on all the papers and articles saying what was wrong with that C code). Those bugs are in the training data , and often not marked as bugs. So when AI generates C code, is it going to avoid making the mistakes that human code made? No, it's going to generate the kind of code it was trained on. How could…

> See, AI was trained on existing data - on all that existing C code out there (sure, and also on all the papers and articles saying what was wrong with that C code). Those bugs are in the training data, and often not marked as bugs. So when AI generates C code, is it going to avoid making the mistakes that human code made? No, it's going to generate the kind of code it was trained on. How could it be otherwise? The…

It still could happen, if they had a way to judge the exceptional outputs from the mid and terrible ones. But I'm not sure they have that...

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

#65

Post by pdimitar »

atherton94027 wrote: post #49
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.

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.

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

#66

Post by MBCook »

senfiaj wrote: post #26

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.

A lot of them are strings coming from or going to user space right? So wouldn’t you have to do constant conversions?

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

#67

Post by WalterBright »

"The strncpy function within the Linux kernel has been a "persistent source of bugs" for years due to counter-intuitive semantics and behavior around NUL termination along with performance issues due to redundant zero-filling of the destination."

Huh. Whenever I've been asked to review C code, I always looked for strncpy and always found a bug with it.

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

#68

Post by MBCook »

clnhlzmn wrote: post #62
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

The way we do it in modern languages with things like std::optional and even that is not the best example.

And higher level languages that works. But what do you do when you get down to low level C or assembly?

You basically end up with null/0 don’t you?

Post reply on HN