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

231–240 of 340 posts

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

#231

Post by AlotOfReading »

Gibbon1 wrote: post #129
AlotOfReading wrote: post #82

Earlier quoted context omitted.

C actually does have a type system and it's one of the bigger issues with the language. If it didn't, unaligned pointers and signed overflow would be totally fine.

Problems with unaligned pointers are basically a hardware defect. Signed overflow is an issue because academics are unhappy computers only can do finite math. Issue with types and C is while the compiler knows about them the standards committees don't want you to be able to. If C had first class types more people would abandon C++ and that can't be allowed to happen.

Unaligned pointers are undefined behavior even when the hardware fully supports unaligned access, because you're violating the type's rules.

To be honest, I've never seen much indication that the C and C++ committees are particularly fond of each other. They sometimes coordinate, but they're mostly content letting each other evolve in different directions. C is the way it is only after a long process of evolution away from the bits and bytes of BCPL into the strictly typed language we got from ASNI.

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

#232

Post by GTP »

rurban wrote: post #225
GTP wrote: post #217

I always thought that srncpy was the safe alternative to strcpy. Now that I think of it, I'm unsure if the NUL terminator is counted into strncpy's size or not, which would be a likely source of errors. But, could someone explain better what the problems were? And also, would have to pick the right function in the list of given alternatives much better?

No, the safe alternatives end with _s. They do check matching buffer sizes, and enforce zero-termination. Unfortunately WG14 hates them also, because Microsoft. Microsoft did indeed break some of the, but you can use better alternatives, like my safeclib

> No, the safe alternatives end with _s.

Could you please elaborate on this? Both `man strncpy_s` and `man strcpy_s` didn't return any manual page on my Linux system.

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

#233

Post by t-3 »

Conscat wrote: post #149
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 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.

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

#234

Post by ptx »

EvanAnderson wrote: post #206
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…

I did a project to translate data framed in the ASCII field/record separator characters and it was gloriously easy. All the ugly escaping considerations with comma-delimited data went away and it became much easier.

What happens when the data contains the record or field separator characters?

I suppose you could document that it's unsupported, and just drop or reject such values, but then the system couldn't be used to handle test data for such systems, for example.

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

#235

Post by EvanAnderson »

ptx wrote: post #234
EvanAnderson wrote: post #206

Earlier quoted context omitted.

I did a project to translate data framed in the ASCII field/record separator characters and it was gloriously easy. All the ugly escaping considerations with comma-delimited data went away and it became much easier.

What happens when the data contains the record or field separator characters? I suppose you could document that it's unsupported, and just drop or reject such values, but then the system couldn't be used to handle test data for such systems, for example.

In the case of this system (a quasi-EDI interface used to move records from a fleet fueling point-of-sale system to the ERP software) those characters were forbidden by the source application. My code would have exploded in a fireball if they had been present, but the specification said they couldn't be.

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

#236

Post by Parodper »

Ekaros wrote: post #216
Parodper wrote: post #215

Earlier quoted context omitted.

LF makes the most sense, but they're all fine for text files. The issue is that CSV isn't text. Last time I had to handle CSV files in bash, I converted them internally to RS and FS.

Line feed resetting position really makes no sense. It should just continue text from where the cursor was but on next line. Like staircase. You need CR to go back to start.

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

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

#237

Post by ethbr1 »

sirwhinesalot wrote: post #140

I have in the past made fun of the Linux kernel devs, supposedly some of the best C developers in the world, for not knowing how to make stringbuffer and stringview types, but to be fair to them we didn't have the consensus we have today on the topic. You know who did have the right idea though? Dennis Ritchie, who proposed a fat pointer type for C all the way back in 1990. Would have made for a perfect addition to C…

> "C's greatest mistake" blog article from Walter Bright in 2007

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

And because it came up in my search and the bikeshedding discussion made me chuckle, reddit on same: https://www.reddit.com/r/C_Programming/comments/90uq7c/cs_bi...

Am curious about this esoterica, if anyone can confirm/deny:

>> Speaking of [C] arrays decaying into pointers, does anyone know why this behaviour was designed in the first place?

>> It was so that B code could be compiled as C with minimal changes. The designer felt that this would encourage people to switch from B to C. In B an array declaration actually defined a pointer and an array, with the pointer initialized to point to the array's first element.

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

#238

Post by fulafel »

sirwhinesalot wrote: post #140

I have in the past made fun of the Linux kernel devs, supposedly some of the best C developers in the world, for not knowing how to make stringbuffer and stringview types, but to be fair to them we didn't have the consensus we have today on the topic. You know who did have the right idea though? Dennis Ritchie, who proposed a fat pointer type for C all the way back in 1990. Would have made for a perfect addition to C…

Link to Ritchie's proposal: https://web.archive.org/web/20150611114358/https://www.bell-...

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

#239

Post by MarkMarine »

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?

Performance. A safe Swiss Army knife function that did most of this would be slow because of the internal branching you’d need to be safe, and because there is developer intent in the selection of these functions. I’d rather have the choice and clear dev intent when I see the function used when reading code.

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

#240

Post by Parodper »

cornholio wrote: post #38
msla wrote: post #15

Earlier quoted context omitted.

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…

You can have a universal variable length field, for example 2 bytes for strings The subdivision issue is a good perspective, but i would argue the performance impact of cloning substrings is dwarfed by the redundant full string reads to find length.

You could do 0xffff as a special case, and put another length+string/pointer to after the 255th byte.
Post reply on HN