Hacker News Reader

Comment by qalmakka | Hacker News Reader

What saddens me is that this is yet another missed opportunity for fixing the C strings library, which is sadly mostly broken beyond repair or straight unusable on modern systems.

Annex K tanking badly was just sad. At least they finally standardized strdup().

View on HN

How do you intend to fix the strings library? beyond strlen() and _maybe_ the search functions like strchr() there really isn't much you should use. And those functions are _fine_.

Some of the string functions, like strtok() or strcat(), and I would also include strdup(), are broken beyond repair and should simply not be used. The only way to "fix" the library would be to remove these functions, but I assume this would create more trouble with legacy code than it's worth.

C strings are mostly a useful storage format for small strings, including string literals, and as a "default" string type for the little basic functionality that is expected to be part of C to support a small program growing up - including printf() and friends.

For longer strings, you are expected to build datatypes that fit your usecase, and that includes decisions about memory management. It should not be the responsibility of the language to make these decisions for you.

By having something like SDS[0] as part of the standard library, but that is clearly asking too much.

[0] - https://github.com/antirez/sds

This is BSTR for the Windows/COM folks.

Replaced by HSTRING on modern times. :)

I get strtok and strcat, but what's wrong with strdup?

It's only very marginally useful, strdup(x) is equivalent to malloc(strlen(x)). It is one of the few functions that allocate, but it doesn't have "alloc" in its name, putting more of an onus on the programmer to free() appropriately. Also, it's advocating bad programming style. Just mallocing random small things all over the place is not how you structure programs well. (Instead, most strings should be in a pool or in another context that is more local than the malloc() heap, so individual strings can be released at once without having to track all the strings attached to a million different structures).

Other POSIX functions, such as glob, also allocate memory and don't have alloc in the name.

It's something that I use. Maybe not frequently, but I definitely use it.

Also, it is in no way equivalent to malloc(strlen(x)). You're off by one byte and you've not copied any of the string.

Oops, see how my mind became lazy when thinking about such a boring, tasteless function? A function like memdup() would be slightly more useful.

At least, glob() has its own globfree() function, leaving room for slightly more mindful organization.

You can't even do strcpy(malloc(strlen(x)+1), x) because it doesn't check that malloc succeeded. strdup does all of this for you! :-)

Maybe your mind would become more engaged if you took the time to understand how the functions worked properly.

I do of course understand how this "works".

> strdup(x) is equivalent to malloc(strlen(x))

Dude. Have you ever typed or said total nonsense because your mind was already busy with the next, more interesting thing?

If things frequently seem nonsense to you perhaps greater reading comprehension skills may help you keep up with busy-minded folk.

What are you up to? I made a fairly clear and simple point but you seem to be hung up on a stupid "typo". And what do you allude to with regards to reading comprehension?

If you frequently make stupid typos perhaps you may enjoy writing lessons to go with the reading comprehension ones.

I think I could recommend a couple lessons to you as well. Have a good day.

Annex K is appalling. It depends on global shared mutable state, so it is incompatible with threading.

The committee is still run by fossils carrying the misguided torch of endless backwards compatibility. No one is compiling 1980s C on GCC trunk releases, but by god we still need to make sure it compiles cleanly.

It usually doesn’t, often it will compile with warnings.

Reply on news.ycombinator.com