4 ms·
As a C programmer, I find this kind of bad faith article very irritating. Yes, the standard library is bad. This is by far the worst part of the C legacy. But
by stephc_int13 5mo ago
As a C programmer, I find this kind of bad faith article very irritating.
Yes, the standard library is bad. This is by far the worst part of the C legacy.
But it is not that hard to write your own.
String functions like this are not difficult at all, and you can use better naming and semantics, write faster code etc.
C is not the C standard library, ffs.
- konmok 5mo agoI don't think it's in bad faith. The distinction between a language and its standard library gets blurry even in theory, and in practice they're nearly inseparable. If a language's standard library has four ways of doing almost the same thing, and they're all fundamentally broken, that's a problem.
- dosisking 5mo ago[flagged]
- stephc_int13 5mo agoIf you read the other articles by the same author on his blog, you'll see that he has some strong and weird opinions about C and UB. Complete BS in my opinion.
- alexfoo 5mo agoExactly. A wrapper that handles all of the edge cases properly and gives proper reporting just gets added to your own library of functions and the devs get used to using it. Much like the code for abstract data types like lists/hashmaps/etc which neither C nor the standard libraries provide. Bonus points for having bespoke linting rules to point out the use of known “bad” functions. In one old project we went through and replaced all instances of sprintf() with snprintf() or equivalent. Once we were happy that we’d got every occurrence we could then add lint rules to flag up any new use of sprintf() so that devs didn’t introduce new possible problems into the code. (Obviously you can still introduce plenty of problems with snprintf() but we learned to give that more scrutiny.)
- 1718627440 5mo ago> like lists/hashmaps/etc which neither C nor the standard libraries provide There is a hashmap implementation though: https://man7.org/linux/man-pages/man3/hsearch.3.html https://man7.org/linux/man-pages/man3/hsearch.3.html
- alexfoo 5mo agoSure there's an implementation, but like the integer comparison functions that sparked this thread there are some severe limitations with the implementation. (In fact, looking at it again, I assume I'd purposely purged it from my memory given how terrible it is.) The non-extensible nature is the biggest one. There are plenty of times when the maximum number of elements needed to be stored will be known in advance. (See the note about hcreate().) Secondly the hserach() implementation requires the keys to be NUL terminated strings since "the same key" is determined using strcmp(). Good luck if you want to use a number, pointer, arbitrary structure or anything else as a key. Any reasonable hash table implementation would not have either of these limitations. Maybe I needed to say: > > like lists/hashmaps/etc which neither C nor the standard libraries provide ... reasonable implementations of.
- steveklabnik 5mo ago“One hashmap for your entire program” is not generally what people mean when they want a hashmap.
- alexfoo 5mo ago> The three functions hcreate_r(), hsearch_r(), hdestroy_r() are reentrant versions that allow a program to use more than one hash search table at the same time.
- thomashabets2 5mo agoWhile snprintf() is better than sprintf(), I find that it's easy for people to not check if the return value is bigger than the provided size. Sure, it prevents a buffer overflow, but there could still be a string truncation problem. Similar to how strlcpy() is not a slam dunk fix to the strcpy() problem.
- wang_li 5mo agoThe thing I find irritating is all the folks who say C is broken because it’s not a write once run anywhere language like JavaScript or python. Part of the deal has always been that the programmer needs to understand the target platform and the target compiler’s behavior.
- mswphd 5mo agoisn't the whole point of C that it's portable assembly though? needing to understand the target platform/compiler's behavior to write correct code seems to cut against that claim quite a bit.
- wang_li 5mo agoNo. What gives that idea? The language doesn't even fix the data size of its primary numerical type. No way anyone thought that was portable.
- konmok 5mo agoIs this sarcasm? I thought C didn't fix the size of int because they were trying to make C programs "portable" between architectures with different natural word sizes. It was a mistake, but I remember that as being the stated reason. I'm happy to be corrected if I'm misremembering my history though.
- wang_li 5mo agoI suppose one could say that they didn't fix the data size so the language would be portable. But I can't see how the intent was that programs would be portable, if you define portable to mean 1:1 functioning across differing platforms.
- prerok 5mo agoWhy would it be a mistake? It's efficient for the target platform. The same code can be compiled for different platforms, yes, but the assembly and machine code will vary significantly, so it could behave differently. Porting to a new platform was usually a very complex process, but the code produced was efficient. Nobody seems to care about this nowadays, though, it seems.
- msie 5mo agoThe people downvoting you are probably not C programmers and love to hate C.
- card_zero 5mo agoI guess trying to write in Rust makes them irritable.