Hacker News Reader

Comment by WalterBright | Hacker News Reader

    struct str {
     char *dat;
     sz len;
    };

It's the same solution D uses, except that it's a builtin type, and works for all arrays. I proposed this solution for C:

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

It's hard to overstate what a huge win this is. D has had 23 years of experience with it, and the virtual elimination of array overflow bugs is just win, win, win.

I will never understand why C keeps adding extensions consisting of marginal features, and ignores this foundational fix. I guess they still aren't tired of buffer overflow bugs always being the #1 security vulnerability of shipped C code (and C++, too!).

View on HN

> It's the same solution D uses

As well as most other languages and many C codebases right? Often with a separate length/capacity so the buffer can be larger than the string.

True, but it turns out that very few arrays need to be resizeable.

Why this and not?

    struct str {
     sz len;
     char dat[];
    };

Those are called "length prefixed strings", or more simply "Pascal strings". The difficulty is one has to reallocate and copy to represent a substring.

Having a pointer in the struct allows you to increase the string's capacity without changing all the references to it.

Changing pointers to include length would require an ABI break on pretty much all platforms. You’d either have to recompile the world or have some sort of bridging thing that converts calls from C-with-fat-pointers to standard C. And even recompiling the world wouldn’t be enough, since lots of C code relies on being able to do things like cast pointers to integers, manipulate them as numbers, then cast them back. That’s UB by the standard but platforms and compilers can and often do define that behavior to be something useful.

You could say, well, forget binary compatibility and forget nasty code that bit-twiddles pointers. But then why are you even using C? Those are the things that set it apart.

Clang is trying to solve this with annotations that allow the programmer to construct fat pointers, either as structures or just implicitly by having the length in a variable somewhere, and enforcing those bounds in the compiler. Seems promising. https://clang.llvm.org/docs/BoundsSafetyImplPlans.html

> Changing pointers to include length would require an ABI break on pretty much all platforms.

Fixed with my proposal: https://www.digitalmars.com/articles/C-biggest-mistake.html

Yeah but not having standard buffer and slice types along with safe API's that require their use is unforgivable.

I'm also of the opinion that a backwards compatibility with null terminated string is actually terrible. Because you want people to eventually go, oh this code uses gross null terminated strings, lets fix that.

> I will never understand why C keeps

Well, I, for one, do like the idea of C (in contrast to D or C++) still being sort of the lowest-level high-level programming language - one that's just a notch above the assembler.

There is nothing particuarly low level about null terminated strings. It is just a convention that a bunch of standard library functions follow. Then there is a dozen variants of each of those standard library functions, most of which end up making you pass in some form of a length parameter anyway, because the convention is so terrible.

At this point, I think we might be in a better world if C simply did not offer any string API in the first place. If

Did your comment get cut off because you embedded a null inside it?

> It is just a convention that a bunch of standard library

That’s not true, this representation of strings (in the form of a literal) is built into the language itself.

Expressing strings as null terminated or in a data structure that includes the size and data has no relationship to it being a higher or lower level language. They still need to determine where a string starts and ends in memory. The means of doing so is different, the assembly language representation will be slightly different, but the language isn't hiding anything behind an abstraction. Contrast that to, say, Pascal where the length of the string is hidden from the developer and can only be accessed through function calls. (It probably should be, but that is beside the point.)

Depending on the Pascal implementation, the length might be accessible actually, but better not mess directly with it.

> one that's just a notch above the assembler.

That has never been true, unless you are writing programs against a PDP-11. C compilers can change even the O complexity of your algorithms, it's nowhere close to assembly.

> C compilers can change even the O complexity of your algorithms

I'd be curious to see an example...

My proposal https://www.digitalmars.com/articles/C-biggest-mistake.html does not take anything away from C's low level abilities.

The usual C mythology continuously spread since the mists of UNIX epoch.

What's lower level on C compared to C++ or D?

Nothing. You can get just as down and dirty in D as you can in C. You just don't have to suffer under the preprocessor as it blasts your kingdom. And you've got a fully functional inline assembler, and modules.

I have heard about an object-oriented assembler (never seen one, though).

Reply on news.ycombinator.com