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

161–170 of 340 posts

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

#161

Post by rswail »

lelanthran wrote: post #148
cornholio wrote: post #38

Earlier quoted context omitted.

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 can have a universal variable length field, for example 2 bytes for strings To hold the length of a string, I'd do something similar to unicode: 7-bits for size + 1-bit for continuation, then 15 bits for size + 1 bit for continuation, then 23-bits for size + 1 bit for continuation, etc. Or maybe even do it exactly the same as unicode: 0XXX XXXX -> length of string is in those 7 bits 1XXX XXXX XXXX XXXX -> lengt…

So what exactly is the NUL/0 in the code below other than a sentinel value?

    while (*d++ = *s++)
        ;

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

#162

Post by rswail »

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…

The C code for strcpy is:

    while (*d++ = *s++)
         ;
On a PDP-11 that is:

    L:  MOV (R1)+, (R2)+
        BNE L

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

#163

Post by cornholio »

lelanthran wrote: post #148
cornholio wrote: post #38

Earlier quoted context omitted.

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 can have a universal variable length field, for example 2 bytes for strings To hold the length of a string, I'd do something similar to unicode: 7-bits for size + 1-bit for continuation, then 15 bits for size + 1 bit for continuation, then 23-bits for size + 1 bit for continuation, etc. Or maybe even do it exactly the same as unicode: 0XXX XXXX -> length of string is in those 7 bits 1XXX XXXX XXXX XXXX -> lengt…

Personally, I would avoid UTF-8 levels of complexity because you only pay the size cost once per string. A simple 2-bytes + optional 4 bytes continuation scheme handles strings up to 140TB and increases the size of the average string by just 2 bytes (compared to 1 byte for nul termination).

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

#164

Post by rswail »

pjmlp wrote: post #142
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…

All those limitations were sorted out in 1978 with Modula-2 and open arrays, aka spans. What about the UNIX and C folks propaganda of C being the first systems language, or always focusing on the original Pascal used for teaching and not everything else that followed up with Mesa, Modula-2, Ada, Object Pascal and friends, none of them with said limitations.

C was specifically developed to allow Unix to be ported.

It was a systems programming language and the first well known/successful one.

There was BCPL and then B before that, which is why the language is called "C".

Pascal was considered a teaching language, along with "Algorithms + Data Structures = Programs" by Wirth etc.

The UCSD P-system was one of the first "IDEs" and used Pascal and a bytecode interpreter of the compiled code.

Modula-2 was barely available in the early 1980s.

Ada was mired in MIL-SPEC and expensive compilers etc.

People used FORTRAN for scientific programming, C for most everything else in the non-IBM mainframe world.

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

#165

Post by qarl »

NetMageSCW wrote: post #137
qarl wrote: post #121

Earlier quoted context omitted.

Well - not really a circle. I keep saying the same thing over and over and you keep throwing arguments at it, unsuccessfully.

I don’t think it’s the arguments that are unsuccessful.

If you have an actual criticism of my argument you'll need to be more clear to be understood.

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

#166

Post by rswail »

In all the comments in this thread it's interesting how people confuse:

* NUL: An ASCII non-printing character with the byte value of 0

* NULL: A pointer that does not point to usable memory with the value that compiles in C to be equal to ((void *) 0).

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

#167

Post by lelanthran »

rswail wrote: post #161
lelanthran wrote: post #148

Earlier quoted context omitted.

> You can have a universal variable length field, for example 2 bytes for strings To hold the length of a string, I'd do something similar to unicode: 7-bits for size + 1-bit for continuation, then 15 bits for size + 1 bit for continuation, then 23-bits for size + 1 bit for continuation, etc. Or maybe even do it exactly the same as unicode: 0XXX XXXX -> length of string is in those 7 bits 1XXX XXXX XXXX XXXX -> lengt…

So what exactly is the NUL/0 in the code below other than a sentinel value? while (*d++ = *s++) ;

I am not sure what this is in response to. Can you explain which point of mine you are responding to?

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

#168

Post by lelanthran »

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…

> Every string function is designed to keep going until it finds the NULL character, so if a hacker gets rid of the NULL character,

What sort of situation are you envisioning where a hacker can remove the sentinel (in the case of nul-termination) but not modify the length bytes (in the case of fat pointers)?

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

#169

Post by lelanthran »

senfiaj wrote: post #45
none_to_remain wrote: post #41

Earlier quoted context omitted.

The size overhead of that is 2*sizeof(int) while the overhead of null termination is sizeof(char). If I remember the standard right, the former is worse by at least sizeof(char), and usually more in practice. This used to matter, sometimes still does.

Well, not saying to always use it, but if the string size is big enough, the overhead of 2 ints becomes relatively vanishing. For generic dynamically sized strings it probably has more advantages than disadvantages. But in any case, sure, if every single byte matters or some structure requires specific memory layout, then fine. I just don't think these things are the majority of use cases. Keep in mind that the cache…

> Well, not saying to always use it, but if the string size is big enough, the overhead of 2 ints becomes relatively vanishing.

In that case, the fix is not to change C strings (breaking a lot of existing code), but to introduce a stringbuilder type.

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

#170

Post by layer8 »

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…

The decision was made almost 55 years ago for C and Unix: https://en.wikipedia.org/wiki/Null-terminated_string#History
Post reply on HN