6 ms·

C people, isn't it perhaps time to quietly pasture the existing standard library and create a new one, from scratch, that isn't chock full of booby traps in the

C people, isn't it perhaps time to quietly pasture the existing standard library and create a new one, from scratch, that isn't chock full of booby traps in the small print?

pjmlp 11y ago
The real problem, how C sees strings, arrays and pointers would still persist. Implicit conversion between vectors and pointers should have never happened. I don't get why people find so hard to write &vector[0] for those cases where a pointer is needed. Also if other languages, for other OS, older than C could do bound checking elision, C not doing it was only saving work for the compiler developer.
- kazinator 11y ago
  If &array[0] were needed, it wouldn't solve anything. The semantics that you can take the pointer to the first element, and pass it around and treat it as an array, with no meta-data connecting it to the original properties of the array, would still be there. The requirement for a cast would be better, because that's the existing notation for explicitly requesting conversions that are identified as unsafe. I.e. char array[42]; char *p = array; /* error, implicit conversion */ char *q = (char *) array; /* OK */ char *s = &array[0]; /* Sneaky: OK, without a cast */
  - pjmlp 11y ago
    Sure, but I was specially thinking about the issue of passing vectors into functions. In any way, for me the right way of doing systems programming is the way of Mesa, Modula-2 and many others. C was already bad in the 70's.
    - kazinator 11y ago
      I programmed quite a bit in Modula-2 before C. It didn't teach me enough to recognize the silliness in C. I believe that this is an aspect of C popularity that hasn't received a lot of recognition. Programmers were sucked away from cleaner languages into C, because the users of the cleaner languages had neglected to acquire the body of rationalizations for why those languages are that way which could have helped them stick. C looked good in naive ways. "Hey, look at all the things you can easily do with memory and pointers! Wow, look at that slick syntax: you can stuff several increments and an assignment into an expression, and use that as the test of a loop, ... man I'm never writing foo := foo + 4; again!" Modula 2's memory management is basically malloc/free though. While the language could save you from array overruns, it is basically defenseless against leaks and use-after-free bugs, as well as uses of unchecked null pointers under OOM: See: http://www.modula2.org/reference/isomodules/isomodule.php?file=STORAGE.DEF http://www.modula2.org/reference/isomodules/isomodule.php?fi... Look, the allocator works with generic pointers, has an explicit DEALLOCATE, and ALLOCATE returns NIL when there is no memory! Modula 2' standard also has a SYSTEM module which adds C-like things: pointer arithmetic, casting and whatnot. http://www.modula2.org/reference/isomodules/isomodule.php?file=SYSTEM.DEF http://www.modula2.org/reference/isomodules/isomodule.php?fi... Is that just "C envy", or is there perhaps need for those things, know what I mean?
      - pjmlp 11y ago
        I came to C from Turbo Pascal (3, 5.5 and 6.0), so it already looked primitive to be back then. Fortunately on the same year I got to learn C++, which allowed me to use most of the features I already knew from Turbo Pascal, alongside better safety if cared about it. Eventually I only used pure C when required to do so at the university and on my first job after the university. Everywhere else the choice between both languages was always C++. Regarding C, when coding in it, I always adopted a Turbo Pascal style by using translation units as if they were modules. With data structures designed as ADTs, without any direct access to its internals, defensively programming and eventually with a little bit of design by contract. > Modula 2's memory management is basically malloc/free though. While the language could save you from array overruns, it is basically defenseless against leaks and use-after-free bugs, as well as uses of unchecked null pointers under OOM: Yes, but there is already a bit list of errors that Modula-2 and similar languages saves one from: - Buffer overruns (unless disabled, of course) - Out parameters being null - Implicit conversions of enumerations into integers - Implicit conversions between numeric types - Strings without terminating null > Is that just "C envy", or is there perhaps need for those things, know what I mean? Of course those features are needed in systems programming, but there is a big difference being safe by default and making explicit use of unsafe code, or just being unsafe everywhere. For example, in Modula-2 if a module imports SYSTEM you already know that module is doing something fishy. In Oberon and Modula-3, like .NET, one could forbid unsafe modules from being loaded. Whereas in C, even code that looks harmless can be doing strange things to the memory state.
sirwolfgang 11y ago
I mean, that pretty much is the entire premise of C++. Which notably does have a full wrapped string class.
- humanrebar 11y ago
  To be fair, maintaining compatibility with existing software (including libc) is the reason, either directly or indirectly, for many (most?) of the gotchas in C++. Then again "your C code is valid C++ code!" was perhaps the biggest selling point of C++ when it came out.
- anton_gogolev 11y ago
  Or, like, dozens and dozens of them, all differing in almost any aspect imaginable. And no, std::string is decidedly not a proper "string class".
  - nly 11y ago
    std::string is a complete replacement for C strings. That is, fixed character width ASCII-or-equivalent strings. That's what it was designed for, and that's what it is. People often complain about the lack of a real "string class" in the standard C++ library. Well, guess what? No language today really has primitives that handle unicode absolutely perfectly, and there's still intense debate about what they should be doing with respect to encodings, length() functions etc. Maybe the answer is that Unicode itself should be simplified so that every word in language has one representation in any particular encoding.
    - twoodfin 11y ago
      It's a replacement for heap-allocated C strings. If you want to use std::string operations on an array of characters that you don't own or that are part of an indivisible larger structure, you're out of luck. It's not difficult to craft a slice-like replacement, but range types will be most welcome when they finally hit the standard.
      - 11y ago
kazinator 11y ago
Every significantly large C program in C's history quietly farms its own library.
- 101914 11y ago
  Opinion: Some not so quietly; in any case, most of them are not worth reusing. But there are exceptions, e.g., stralloc.h Opinion: Personally, because I strive to learn more than to be "productive", I prefer languages that force the author to write her own libraries. As I see it, the alternative is languages that discourage this, effectively coercing the author to use other people's libraries, the quality over which she has no control. Opinion: For me, the bad part is that there are so many poorly thought out C functions in the wild (even including the "standard" ones); the good part is that the C language encourages authors to write their own libraries. Given the choice, I still prefer assembly to C. I guess this is because I prefer to write small programs; perhaps I am not smart enough to write large ones.
  - chinpokomon 11y ago
    Are you not making an assumption about your own code then? The strength of open software is that you don't have to rely on one person to have solved everything. I consider myself to be a good developer, better than most for some areas, but I know there are others who have written better code for other areas. I prefer not to reinvent the wheel when I know my implementation won't be any better, or if I were able to make a better wheel, that will be time spent that I wasn't reinventing the carriage.
    - deleted 11y ago
      [deleted]
belorn 11y ago
There is one, and it exist inside the gnu libc. strndup performs identical to strncpy except that it always terminates the destination string. (https://www.gnu.org/software/libc/manual/html_node/Copying-and-Concatenation.html https://www.gnu.org/software/libc/manual/html_node/Copying-a...)
- jpollock 11y ago
  strndup is not a replacement for strncpy, it allocates memory, whereas strncpy takes an existing buffer. In-place memory usage is very important for preparing anything of a fixed size (structs) to be written out to disk or the network.
- JulianMorrison 11y ago
  You remember the Holy Grail scene from Indiana Jones? The problem is not the absence of the grail, somewhere on the shelf. The problem is all the others and the fact that if you pick the wrong one, your program desiccates, crumbles to dust, and is blown away by a conveniently dramatic wind. A grail shelf that wasn't intended as a booby trap would contain one cup, the right one.
  - pjc50 11y ago
    But this is the great advantage of C! It's one Holy Grail for every platform! Choice is wonderful! /sarcasm
lmm 11y ago
Most people who would be in a position to switch to such a library have already migrated to a safer language than C.
pjc50 11y ago
Backwards-incompatible change breaks code. And it may do so silently. And the C standardisers don't really have the political clout to do this. Trying to force people to "new C" would be a lot of work and would probably result in a culture split like the backwards-incompatible Perl and Python splits. OpenBSD have managed to move people to strlcpy(), but that's about it. People are just as likely to migrate to another language (Rust? Go? Even C++) as upgrade the old C code.
- PythonicAlpha 11y ago
  But it would be possible to create new functions with new names that supersede the old ones, so that the old stdc-lib will be discontinued silently.
  - pjc50 11y ago
    ? Either you discontinue the old functions "noisily", by breaking code that uses them, or they continue to be used.
    - PythonicAlpha 11y ago
      When you have good replacements, at least serious developers will use them. Also there are tools to check for compliance. I don't think, that you can discontinue strcpy and co.
    - JulianMorrison 11y ago
      You add them along side, and you define them as the "modern" standard, and you discourage, but do not forbid, mixing them up. Ideally, there would be no temptation to mix them up in new code, because the new ones would just b better. Including them into old established code (that can't realistically be re-written) is harmless.
PythonicAlpha 11y ago
At least, there are some corners that would need to be addressed. A new, better standard library would provide safer string handling and omit the traps that where left out for years to preserve compatibility. The C++ standard seems to get much more attention than C. C seems to be the step-daughter of programming languages, but still so many projects rely simply on standard C (and not C++).
tjr 11y ago
C was the first programming language I learned well. I've co-written two books on C programming. I've built software ranging from text adventure games to flight management networking software in C. I personally now avoid C as much as possible.

C people, isn't it perhaps time to quietly pasture the existing standard library and create a new one, from scratch, that isn't chock full of booby traps in the small print?

pjmlp 11y ago

The real problem, how C sees strings, arrays and pointers would still persist. Implicit conversion between vectors and pointers should have never happened. I don't get why people find so hard to write &vector[0] for those cases where a pointer is needed. Also if other languages, for other OS, older than C could do bound checking elision, C not doing it was only saving work for the compiler developer.

kazinator 11y ago
If &array[0] were needed, it wouldn't solve anything. The semantics that you can take the pointer to the first element, and pass it around and treat it as an array, with no meta-data connecting it to the original properties of the array, would still be there. The requirement for a cast would be better, because that's the existing notation for explicitly requesting conversions that are identified as unsafe. I.e. char array[42]; char *p = array; /* error, implicit conversion */ char *q = (char *) array; /* OK */ char *s = &array[0]; /* Sneaky: OK, without a cast */
- pjmlp 11y ago
  Sure, but I was specially thinking about the issue of passing vectors into functions. In any way, for me the right way of doing systems programming is the way of Mesa, Modula-2 and many others. C was already bad in the 70's.
  - kazinator 11y ago
    I programmed quite a bit in Modula-2 before C. It didn't teach me enough to recognize the silliness in C. I believe that this is an aspect of C popularity that hasn't received a lot of recognition. Programmers were sucked away from cleaner languages into C, because the users of the cleaner languages had neglected to acquire the body of rationalizations for why those languages are that way which could have helped them stick. C looked good in naive ways. "Hey, look at all the things you can easily do with memory and pointers! Wow, look at that slick syntax: you can stuff several increments and an assignment into an expression, and use that as the test of a loop, ... man I'm never writing foo := foo + 4; again!" Modula 2's memory management is basically malloc/free though. While the language could save you from array overruns, it is basically defenseless against leaks and use-after-free bugs, as well as uses of unchecked null pointers under OOM: See: http://www.modula2.org/reference/isomodules/isomodule.php?file=STORAGE.DEF http://www.modula2.org/reference/isomodules/isomodule.php?fi... Look, the allocator works with generic pointers, has an explicit DEALLOCATE, and ALLOCATE returns NIL when there is no memory! Modula 2' standard also has a SYSTEM module which adds C-like things: pointer arithmetic, casting and whatnot. http://www.modula2.org/reference/isomodules/isomodule.php?file=SYSTEM.DEF http://www.modula2.org/reference/isomodules/isomodule.php?fi... Is that just "C envy", or is there perhaps need for those things, know what I mean?
    - pjmlp 11y ago
      I came to C from Turbo Pascal (3, 5.5 and 6.0), so it already looked primitive to be back then. Fortunately on the same year I got to learn C++, which allowed me to use most of the features I already knew from Turbo Pascal, alongside better safety if cared about it. Eventually I only used pure C when required to do so at the university and on my first job after the university. Everywhere else the choice between both languages was always C++. Regarding C, when coding in it, I always adopted a Turbo Pascal style by using translation units as if they were modules. With data structures designed as ADTs, without any direct access to its internals, defensively programming and eventually with a little bit of design by contract. > Modula 2's memory management is basically malloc/free though. While the language could save you from array overruns, it is basically defenseless against leaks and use-after-free bugs, as well as uses of unchecked null pointers under OOM: Yes, but there is already a bit list of errors that Modula-2 and similar languages saves one from: - Buffer overruns (unless disabled, of course) - Out parameters being null - Implicit conversions of enumerations into integers - Implicit conversions between numeric types - Strings without terminating null > Is that just "C envy", or is there perhaps need for those things, know what I mean? Of course those features are needed in systems programming, but there is a big difference being safe by default and making explicit use of unsafe code, or just being unsafe everywhere. For example, in Modula-2 if a module imports SYSTEM you already know that module is doing something fishy. In Oberon and Modula-3, like .NET, one could forbid unsafe modules from being loaded. Whereas in C, even code that looks harmless can be doing strange things to the memory state.

sirwolfgang 11y ago

I mean, that pretty much is the entire premise of C++. Which notably does have a full wrapped string class.

humanrebar 11y ago
To be fair, maintaining compatibility with existing software (including libc) is the reason, either directly or indirectly, for many (most?) of the gotchas in C++. Then again "your C code is valid C++ code!" was perhaps the biggest selling point of C++ when it came out.
anton_gogolev 11y ago
Or, like, dozens and dozens of them, all differing in almost any aspect imaginable. And no, std::string is decidedly not a proper "string class".
- nly 11y ago
  std::string is a complete replacement for C strings. That is, fixed character width ASCII-or-equivalent strings. That's what it was designed for, and that's what it is. People often complain about the lack of a real "string class" in the standard C++ library. Well, guess what? No language today really has primitives that handle unicode absolutely perfectly, and there's still intense debate about what they should be doing with respect to encodings, length() functions etc. Maybe the answer is that Unicode itself should be simplified so that every word in language has one representation in any particular encoding.
  - twoodfin 11y ago
    It's a replacement for heap-allocated C strings. If you want to use std::string operations on an array of characters that you don't own or that are part of an indivisible larger structure, you're out of luck. It's not difficult to craft a slice-like replacement, but range types will be most welcome when they finally hit the standard.
    - 11y ago

kazinator 11y ago

Every significantly large C program in C's history quietly farms its own library.

101914 11y ago
Opinion: Some not so quietly; in any case, most of them are not worth reusing. But there are exceptions, e.g., stralloc.h Opinion: Personally, because I strive to learn more than to be "productive", I prefer languages that force the author to write her own libraries. As I see it, the alternative is languages that discourage this, effectively coercing the author to use other people's libraries, the quality over which she has no control. Opinion: For me, the bad part is that there are so many poorly thought out C functions in the wild (even including the "standard" ones); the good part is that the C language encourages authors to write their own libraries. Given the choice, I still prefer assembly to C. I guess this is because I prefer to write small programs; perhaps I am not smart enough to write large ones.
- chinpokomon 11y ago
  Are you not making an assumption about your own code then? The strength of open software is that you don't have to rely on one person to have solved everything. I consider myself to be a good developer, better than most for some areas, but I know there are others who have written better code for other areas. I prefer not to reinvent the wheel when I know my implementation won't be any better, or if I were able to make a better wheel, that will be time spent that I wasn't reinventing the carriage.
  - deleted 11y ago
    [deleted]

belorn 11y ago

There is one, and it exist inside the gnu libc. strndup performs identical to strncpy except that it always terminates the destination string. (https://www.gnu.org/software/libc/manual/html_node/Copying-and-Concatenation.html https://www.gnu.org/software/libc/manual/html_node/Copying-a...)

jpollock 11y ago
strndup is not a replacement for strncpy, it allocates memory, whereas strncpy takes an existing buffer. In-place memory usage is very important for preparing anything of a fixed size (structs) to be written out to disk or the network.
JulianMorrison 11y ago
You remember the Holy Grail scene from Indiana Jones? The problem is not the absence of the grail, somewhere on the shelf. The problem is all the others and the fact that if you pick the wrong one, your program desiccates, crumbles to dust, and is blown away by a conveniently dramatic wind. A grail shelf that wasn't intended as a booby trap would contain one cup, the right one.
- pjc50 11y ago
  But this is the great advantage of C! It's one Holy Grail for every platform! Choice is wonderful! /sarcasm

lmm 11y ago

Most people who would be in a position to switch to such a library have already migrated to a safer language than C.

pjc50 11y ago

Backwards-incompatible change breaks code. And it may do so silently. And the C standardisers don't really have the political clout to do this. Trying to force people to "new C" would be a lot of work and would probably result in a culture split like the backwards-incompatible Perl and Python splits. OpenBSD have managed to move people to strlcpy(), but that's about it. People are just as likely to migrate to another language (Rust? Go? Even C++) as upgrade the old C code.

PythonicAlpha 11y ago
But it would be possible to create new functions with new names that supersede the old ones, so that the old stdc-lib will be discontinued silently.
- pjc50 11y ago
  ? Either you discontinue the old functions "noisily", by breaking code that uses them, or they continue to be used.
  - PythonicAlpha 11y ago
    When you have good replacements, at least serious developers will use them. Also there are tools to check for compliance. I don't think, that you can discontinue strcpy and co.
  - JulianMorrison 11y ago
    You add them along side, and you define them as the "modern" standard, and you discourage, but do not forbid, mixing them up. Ideally, there would be no temptation to mix them up in new code, because the new ones would just b better. Including them into old established code (that can't realistically be re-written) is harmless.

PythonicAlpha 11y ago

At least, there are some corners that would need to be addressed. A new, better standard library would provide safer string handling and omit the traps that where left out for years to preserve compatibility. The C++ standard seems to get much more attention than C. C seems to be the step-daughter of programming languages, but still so many projects rely simply on standard C (and not C++).

tjr 11y ago

C was the first programming language I learned well. I've co-written two books on C programming. I've built software ranging from text adventure games to flight management networking software in C. I personally now avoid C as much as possible.