Hacker News Reader

All good points, which are part of the reasons I used other languages, but I'm back to C after weighing in those pros and cons.

There is no perfect language, C just seems the best for me to get job done.

As long as one understands the tradeoffs, no problem.

There is nothing stopping you from storing size of the string. See: UNICODE_STRING

This is a silly argument.

Null terminated string are never meant to use for large buffers. For all small strings that just locally it serves its purpose nicely. C designer realized that there is no way to have a standard way to deal with large performance-critical buffers , so they choose not to do it. Which is exactly the reason why C is so powerful - not necessarily fast but never get in your way if you want to.

For array bounds checking, if you want it, just a write a structure with buffer length and a getter setter and it is done. People complain this write zillions of getter setters in other languages but just choose to complain in case for C.

> For array bounds checking, if you want it, just a write a structure with buffer length and a getter setter and it is done.

It's so easy, yet buffer overflows remain the #1 problem in shipped C code.

> For all small strings that just locally it serves its purpose nicely.

Not really. Whenever I review other peoples' C code, I look at their use of strlen/strncpy/strxxx functions. They're a rich source of bugs, and I'll usually find one in it (usually an off-by-one error). They don't have to be large strings, either, to be slow.

It just means not that many people give a damn about buffer overflows anyway. And put that situation to language’s fault just doesn’t make sense.

You are saying C string is slow, I am telling you short local strings are not slow, please tell me why it is slow in that case?

OK you've done a bunch of real-world projects. Here's what I never understood. Why didn't some pseudo-standard for strings develop where they created a string-like type that remained null terminated but also included a big int at the beginning with a length value?

Bigint? How often are we dealing with strings over 4GiB?

It would sure open up possibilities. Besides, I was like to plan ahead ;)

I was under the impression that C strings were inherently very fast because of how incredibly cache-friendly they are. You should not ever have to count all the bytes (memoize that!) but if you do, this is the best format there is for it.

What makes you say that? Besides C strings (pointer to characters, null-terminated) we have Pascal strings (pointer to length, followed by the characters), and then there is the variant that I'm not sure what it's called, that consists of a pair of (pointer, length). The last variant is my favorite, an is much nicer to use: you can take substrings without making a copy, you never have to iterate a string to find out its length, and your strings can contain the NULL character (which happens to be a perfectly normal unicode character).

VAX/VMS called them "descriptors", which had IIRC 16 bits of flags, a 16-bit length, and a 32-bit pointer -- descriptors could be used for different object types, not just strings. The 64k length limit and 32-bit address were not a big issue back in 1982 when I first used them.

I used (Wirth's standard) Pascal in our compiler class in college. String handling was actually pleasant in Fortran-77 on VMS, so I figured pure Pascal had the worst string handling of any language -- until I started programming in C. I finally made peace with C strings, but a couple of decades later, Forth said to me, "Here, hold my beer." I wrote some Forth-word equivalents of some of the C Library string functions to make my life a little easier! :)

I'm not sure what it's called

In D we call them dynamic arrays. They could be called length-delineated strings.

It seems that Wikipedia refers to them as "Strings as records"[1], which I suppose fits quite well. I suppose that C strings could be considered "the most" cache friendly since it has only 1 byte overhead instead of however many bytes would be required for the length (probably 4 or 8 bytes on most modern systems). That said, I would be extremely surprised for this difference of a few bytes per string to have a measurable performance improvement in anything but an unrealistic microbenchmark involving many tiny strings.

1: https://en.wikipedia.org/wiki/String_(computer_science)#Stri...

0 terminated strings make sense for extremely tight memory cases, like 64Kb computers, and CPUs that don't cache memory. But they're a clear loser for 32 bit machines.

> 0-terminated C strings are slow. There's the constant need to scan the string to determine its length.

Just record it once

Record it where? Hence lie the bugs as C doesn't offer a reliable way to associate the two.

I made a proposal to fix this in C, but it went nowhere:

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

Not trying to be a troll, but is this benefit anything more than having to carry two variables? As in, is this about getting the length without having to use str Len even once?

If it's part of the type, then the compiler can automatically insert bounds checks. If not, then you'll have to insert the checks manually, which we both know won't happen.

Another trouble with two variables is there's no obvious connection between them. One can be modified without the other, etc.

Obviously, a struct is one option. The problem is that you then need to make a whole string library. Thankfully, many exist, so this is a non issue, unless there's a requirement that you write all the code yourself.

A struct won't be recognized by the language in order to automatically insert array bounds checks.

> Thankfully, many exist, so this is a non issue

Many string libraries that are incompatible with each other. This is a huge issue. (I myself made many C string libraries. It's not so easy. Try it.)

The language extension I proposed for C is the same one D uses. D has had it for 20+ years, and it has proven very, very satisfactory.

> A struct won't be recognized by the language in order to automatically insert array bounds checks.

If you want automatic bounds checks, then C is not the language for you.

> This is a huge issue.

Could you give an example where it's a huge problem? I'm probably limited by my experience. All of the codebases I've worked on used a single string library. When passing externally/to other libraries, boring C interfaces were used, then those libraries do what they wish from there. The string libraries I've used were mostly, deep down, just structs, with a length member, char pointer member, and encoding stuffs. Passing to the other library almost always ended up just being those member values being passed as arguments to a function, which were copied to the nearly identical structs of the other string library.

Sure. The C Standard library relies on 0 terminated strings. The Linux API relies on 0 terminated strings. Every C library I've every used relied on 0 terminated strings for its interface.

So you use a translation layer. Sorry, I just don't like them, but if you're fine putting these on all your interfaces with other libraries, well, what can I say? :-)

> If you want automatic bounds checks, then C is not the language for you.

I would reframe that as: "if you're ok with buffer overflow malware injection, then C is the language for you!" Nobody has yet figured out how to stop that.

The sad thing is it's so fixable with just a minor, compatible change to C.

> I would reframe that as: "if you're ok with buffer overflow malware injection, then C is the language for you!" Nobody has yet figured out how to stop that.

Write manual bound checks and good code in general? Granted you won't be able to catch every vulnerability, but at some point other vectors are so much easier to exploit that you won't have to worry about these anymore.

Oh, of course! Just write good code! Well kiss my grits. I can't believe the solution has been sitting here staring me in the face all this time.

I promise I'll write good code from now on. Scout's honor.

Even John Carmack thinks "writing good code" is impossible: https://youtu.be/I845O57ZSy4?t=1351 ; p

> Write manual bound checks and good code in general?

40 years of C buffer overflows argues that doesn't work.

C is designed with a computing model in mind (the way memory works, the way arithmetic operations work, the way addressing works etc.). And its language idioms are designed to fall strictly in line with that computing model.

There's very little difference in C between a character string, an array of Bytes, or even a struct of appropriate size. Other than the types and other user friendly (relative to assembly) features that C adds. This is deliberate; yep, it makes working with text harder (and maybe slower) than is necessary, but C doesn't assume that text is something you ever need to represent in your programs by default. So if you need to work with a lot of text, you should find a library for it, or write a library for it.

C isn't designed to be fast (though it often is). It's not designed to be safe (though it also often is). It's designed to be extremely precise, like a hardware description, or a good maths paper.

Some people like that precision. More often, people need that level of precision (see Linus' comments about C over C++ in the Linux kernel).

> Linus' comments about C over C++ in the Linux kernel

For someone of his computing calibre, I found his take on C++ surprisingly... immature. He never truly justifies exactly why he feels C++ is bad in his rants[0][1]; furthermore, he resorts to rather poor logic, which boils down to essentially C++ is bad because the programmers using it are bad.

Perhaps when he did attempt to use it, C++ was equally as immature, and the tooling and compilers were sub-optimal, and there was no RAII, nor std::algorithm, nor any of the niceties available with C++11 (it got better still with C++20's concepts, ranges, std::format, modules, etc).

I daresay that C++ is equally as precise (honestly, I'm not quite sure how to parse this in context) and perhaps even fills in the gaps where the the programmer's intention and their code diverge.

[0]: https://lwn.net/Articles/249460/

[1]: https://developers.slashdot.org/story/21/04/17/009241/linus-...

For the record, I attempted Rust. While it looks nice, I am personally more partial to the by-default freedoms that C++ gives, together with judicious use of sanitisers. If not a systems language, then I default to .NET.

RAII was in C++ around 1985 or so.

> There's very little difference in C between a character string, an array of Bytes, or even a struct of appropriate size.

This is really bad!

> It's designed to be extremely precise, like a hardware description.

This is absolute nonsense. There's far too much undefined behavior in C for it to be described as precise with a straight face.

More generally, C's lack of memory safety has been directly responsible for innumerable vulnerabilities and trillions of dollars in costs to society. It is unacceptable and irresponsible to start a new project that's meant for public use in C in 2022.

Hardware description languages also have tons of undefined behaviour. Electronics, in general, has physical conditions it can be in that will not resolve to a finite value in a finite amount of time.

linux,openbsd,systemd etc are all in c,c looks ok to me today.

Indeed security researchers appreciate they keeping food at their table, see CVE database.

All of them have had massive security vulnerabilities, and almost certainly (at least Linux and systemd) have many publicly undiscovered ones that are currently being exploited by state actors today.

The C Standard library bakes in the use of 0-termination for strings. There's nothing about 0 terminated strings that is the way CPUs work.

C defines an abstract computing model. It's not that CPU's work with 0 terminated strings. It's that the compiler will always ensure that 0 terminated strings make sense on any arbitrary architecture.

If you're a hardware designer building a microcontroller for a gas heater, you can just target the 'C' model, and you can have a high degree of confidence that anything defined by C will work.

This isn't the case for say Python, since lots of behaviour is defined abstractly in terms of API's and program behaviour (what we want the programmer to worry about), not in terms of memory allocation, and register widths etc. That a hardware designer can design to.

An additional aspect of C that I really appreciate is that if something can be conceptually realized, it can be implemented in C. This is not the case with many other languages where you are often constrained by them - either accidentally or intentionally, for safety or other reasons. In most cases you will end up having to write a C shim to do the deed and make available libraries to the other language. C toys the rescue, again!

D and its runtime are 100% implemented in D. D could implement the C Standard library as well, but there's no point to that, since it exists and is what it is.

Can you explain what you mean with an example? Sorry I’m a bot tier swe since I mostly code in node and go

Been a while, but an example would be the ability to work with rawsockets. You can't use this in most higher-than-C languages as this was not, perhaps wisely, considered useful for most people and hence there is no mechanism provided.