[adwn]

> it is kind of wrong to blame the tool for the mistakes made by the one wielding it

I strongly disagree. I think it is absolutely legitimate to blame a tool which is practically impossible to use correctly [1]. Some of C's design decisions were justified in its historical context, and some – like zero-terminated strings – were indefensible even back then.

[1] Alternatively, you could blame its creators, but that's not very useful.

[flohofwoe]

Zero terminated strings make sense when you consider the pecularities of the PDP instruction set.

Snippet from "https://dave.cheney.net/2017/12/04/what-have-we-learned-from...":

One can write a string copy routine using two instructions, assuming that the source and destination are already in registers.

    loop:   MOVB (src)+, (dst)+
            BNE loop

The routine takes full advantage of the fact that MOV updates the processor flag. The loop will continue until the value at the source address is zero, at which point the branch will fall through to the next instruction. This is why C strings are terminated with zeros.

[pjmlp]

Except the world stop being a PDP-11 around 1980's, while ISO C refuses to update itself to modern times.

The biggest issue with C isn't its footguns, rather the WG14 unwillingness to provide additional language or library features that would allow for a safer C outside the low level code where it pretends to be a portable macro assembler.

[flohofwoe]

In the early years the job of the C committee wasn't to improve C, but merely to harmonize existing C implementations, and by the end of the 80's it was already too late, zero-terminated strings had already been baked into operating system APIs (e.g. zero-terminated strings are no longer primarily a language problem, but an ABI problem).

Besides, the x86 "repeat while" string instructions continued the PDP legacy.

[kortex]

That argument sounds akin to "Well people are used to driving without seatbelts, it'd be painful to make them switch now."

Or like my spouse likes to joke when we get in the car to leave and forgot something in the house: "it's too late, the door's shut."

I get why null terminated strings once existed. It's baffling that they continue to exist 50 years later. Not to mention, they don't even work on data buffers, so you need fat pointers anyways!

[flohofwoe]

Replacing the string memory layout in operating system APIs is more similar to changing the track width on an existing railroad network, across the whole world.

It may be a good idea from a theoretical standpoint, but once you start calculating the cost it simply doesn't make sense.

[kortex]

Obviously not with that attitude. I'm not even talking about back-porting. I'm saying going forward, in new drivers and extensions, and new growth where it makes sense to do so.

There's even plenty of means for backwards-compatible strings and arrays, such as sds.

But really the point was more to "this should have really been addressed decades ago."

https://github.com/antirez/sds

[pjmlp]

Liability and lawsuits due to security exploits will take care of that.

Thankfully they are starting to pick up.

[pjmlp]

We aren't speaking about ANSI/ISO C89 here, rather in what happened the following 32 years.

[flohofwoe]

That doesn't matter, even C doesn't matter in that regard anymore, or the opinion of any other language on the best string memory layout. Once zero-terminated strings leaked into operating system APIs the damage was done forever, and there never was a good time to fix the problem afterwards.

[pjmlp]

That is no excuse not to try to improve the status quo.

Maybe liability and lawsuits are really needed to stop with such excuses.

[fragbait65]

I think some incremental improvements could be done for C, question is if it's worth the time?

Maybe it's better to just use a better tool for new code bases?

[pjmlp]

Except embedded developers and UNIX clones will never move beyond C.

[fragbait65]

Well, I agree that you can wish that the tool was better designed, that's a whole different thing though.

What I meant to say, in a rather roundabout way to be fair, is that the problem is both the language and the programmers. C is a tool that is too hard to use correctly, but the programmers who write crappy C code are to blame for their crappy code. It's another thing if an expert fails to use the tool safely, then one might blame the design of the tool used.

There seems to be 2 camps, one camp blames C and one camp blame it on poor programmers. Poor programmers have given C a reputation and the tool itself is too hard to use correctly, even for experts, so both camps are right and also wrong...

I think some of the decisions made for C back in the day where fine, C was designed to be lightning fast and close to the metal, but I think it's time to pivot. I don't think it's necessary to sacrifice security to squeeze out the last percent of "speed" today. C has a lot of legacy code still in use though, so I don't think it will ever happen, that's why I use other languages for production code today and only write C when needed for C code bases still in use.

[flohofwoe]

There's a lot of room to explore between C and Rust, while not compromising on low-level features and performance (e.g. "performance" and "safety" are both not absolutes, and also not excluding each other. I hope that there will be many new languages (the more the merrier) exploring that space.

But we'll live for a very long time with C code, it will most likely outlive us all, because important infrastructure code is never really replaced, it just becomes a new sediment layer.

[pjmlp]

Which is why stuff like Checked C, or something like SDS should really be made part of C, as UNIX clones are going to outlive us anyway.

However just like rotating blade covers, butcher metal gloves, seat belts, helmets,..., apparently external forces like government regulations are required to make WG14 act accordingly.

[pjmlp]

It was already known to Dennis and Ritchie that C without appropriate tooling wasn't an ideal tool, hence why C's history of static analysis goes all the way back to 1979.

Unfortunately, the large majority to this day thinks they don't need such kind of tooling.

"Although the first edition of K&R described most of the rules that brought C's type structure to its present form, many programs written in the older, more relaxed style persisted, and so did compilers that tolerated it. To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for separate compilation, Steve Johnson adapted his pcc compiler to produce lint [Johnson 79b], which scanned a set of files and remarked on dubious constructions. "

https://www.bell-labs.com/usr/dmr/www/chist.html