4 ms·

Well, I was not expecting to read a 10,000-word article about the C standard library this morning. I haven't been programming in C as long as many here, but ove

Well, I was not expecting to read a 10,000-word article about the C standard library this morning. I haven't been programming in C as long as many here, but over the past dozen years or so I've always felt that the standard library is a half-baked hodgepodge of inconsistencies and a minefield of gotchas that have caused innumerable security vulnerabilities. Why is open() in fcntl.h and close() in unistd.h? Why does bcopy go src,dst but memcpy go dst,src? Why did they make strlcpy return a different value than strncpy, so you can't improve a whole codebase with one recursive sed? There are many questions I still have, but I learned a bunch of new things from this article. Thanks to the author for putting the effort into digesting the source material for us. On a tangential topic, I don't know of a good reference for exploring what is included in the standard library. Yes, of course there are manpages for individual families of functions. But I don't know how anyone would find out about, say, strtok or strsep without encountering them in some existing code. I had a university assignment which would have been trivial if anyone in the class knew that fts.h existed.

quietbritishjim 8y ago
Why is open() in fcntl.h and close() in unistd.h? Why does bcopy go src,dst I don't know about the rest, but open(), close() and bcopy() are not in the C standard library. They are either POSIX or Linux specific. The C standard library functions for files start with f e.g. fopen(), fclose(). On a tangential topic, I don't know of a good reference for exploring what is included in the standard library. The classic book The C Programming Language covers most, if not all, of the standard library. The whole thing can be found in an appendix. Admittedly reading an appendix isn't normally the best way to learn about something, but the library is so small and the amount not already covered in the text is even smaller so it wouldn't take long to skim. Of course it doesn't cover Unix-specific functions, like the unistd.h header; for that, I recommend Advanced Programming in the Unix Environment.
- tonysdg 8y ago
  I'd add that The C Programming Language should be seen as a tutorial (albeit an older one that no longer is fully up-to-date in best practices, in my experience) that can serve as a reference in a pinch (it skimps a bit on the corner cases if memory serves). Advanced Programming in the Unix Environment, conversely, should be seen as a reference book with fantastic examples and discussion on error handling -- yes, you can use it as a tutorial, but it's a tad dense and you'll likely never need a lot of it.
- loeg 8y ago
  None of these are Linux specific :-). All were in POSIX; bcopy was deprecated in the 2004 iteration and removed in 2008.
jstimpfle 8y ago
> I've always felt that the standard library is a half-baked hodgepodge of inconsistencies It is! > Why is open() in fcntl.h and close() in unistd.h? Because they don't belong together. open() is used to create an FD using a filesystem path. There are other ways to create FDs, like socket(). close() is used to close any FD. You could say open() has an unfortunate name. Neither open() nor close() are part of the C standard library, though. The standard library has the fopen() and fclose() functions, both defined in stdio.h. (And it's the same situation there: There are other ways to create a FILE than using fopen(), while fclose() can close any FILE (although fopen() is probably the only way defined in the standard library)). > Why did they make strlcpy return a different value than strncpy My advice is to just write your own string data structures and functions. Make the interface that you need. It's often bad to use C strings, anyway (they don't have an explicit length). > But I don't know how anyone would find out about, say, strtok or strsep without encountering them in some existing code. Man pages cross-reference similar functions. And there are index-manpages. For example, strcpy(3) references string(3) which lists all the functionality from string.h, including strtok(3). > I had a university assignment which would have been trivial if anyone in the class knew that fts.h existed. Never knew that one either. Not part of the C standard library I guess. Also, just write your own code. In my opinion the standard library is mainly useful for portable access to basic OS services.
- beefhash 8y ago
  > > I had a university assignment which would have been trivial if anyone in the class knew that fts.h existed. > Never knew that one either. Not part of the C standard library I guess. fts(3) is a BSD interface. It got introduced in 4.3BSD-Reno.
  - dfox 8y ago
    fts(3) is also in SuSv3, but last time I checked it was not available on Solaris (but that was like 10 years ago). More portable but more limited equivalent is ftw(3).
    - caf 8y ago
dfox 8y ago
Somewhat relevant fact is that almost any hosted environment (including MSVC) actually implements large subset of POSIX functions that are not part of C standard. And this does not only consist of OS interface functions but also of various general purpose userspace-only algorithms and data structures.
spc476 8y ago
The post was based up the book The Standard C Library by P. J. Plauger. It's an excellent reference (if a bit dated as it only covers C89) that not only prints the relevant bits from the C Standard, but goes into the history behind the functions and provides an implementation.

quietbritishjim 8y ago

Why is open() in fcntl.h and close() in unistd.h? Why does bcopy go src,dst I don't know about the rest, but open(), close() and bcopy() are not in the C standard library. They are either POSIX or Linux specific. The C standard library functions for files start with f e.g. fopen(), fclose(). On a tangential topic, I don't know of a good reference for exploring what is included in the standard library. The classic book The C Programming Language covers most, if not all, of the standard library. The whole thing can be found in an appendix. Admittedly reading an appendix isn't normally the best way to learn about something, but the library is so small and the amount not already covered in the text is even smaller so it wouldn't take long to skim. Of course it doesn't cover Unix-specific functions, like the unistd.h header; for that, I recommend Advanced Programming in the Unix Environment.

tonysdg 8y ago
I'd add that The C Programming Language should be seen as a tutorial (albeit an older one that no longer is fully up-to-date in best practices, in my experience) that can serve as a reference in a pinch (it skimps a bit on the corner cases if memory serves). Advanced Programming in the Unix Environment, conversely, should be seen as a reference book with fantastic examples and discussion on error handling -- yes, you can use it as a tutorial, but it's a tad dense and you'll likely never need a lot of it.
loeg 8y ago
None of these are Linux specific :-). All were in POSIX; bcopy was deprecated in the 2004 iteration and removed in 2008.

jstimpfle 8y ago

> I've always felt that the standard library is a half-baked hodgepodge of inconsistencies It is! > Why is open() in fcntl.h and close() in unistd.h? Because they don't belong together. open() is used to create an FD using a filesystem path. There are other ways to create FDs, like socket(). close() is used to close any FD. You could say open() has an unfortunate name. Neither open() nor close() are part of the C standard library, though. The standard library has the fopen() and fclose() functions, both defined in stdio.h. (And it's the same situation there: There are other ways to create a FILE than using fopen(), while fclose() can close any FILE (although fopen() is probably the only way defined in the standard library)). > Why did they make strlcpy return a different value than strncpy My advice is to just write your own string data structures and functions. Make the interface that you need. It's often bad to use C strings, anyway (they don't have an explicit length). > But I don't know how anyone would find out about, say, strtok or strsep without encountering them in some existing code. Man pages cross-reference similar functions. And there are index-manpages. For example, strcpy(3) references string(3) which lists all the functionality from string.h, including strtok(3). > I had a university assignment which would have been trivial if anyone in the class knew that fts.h existed. Never knew that one either. Not part of the C standard library I guess. Also, just write your own code. In my opinion the standard library is mainly useful for portable access to basic OS services.

beefhash 8y ago
> > I had a university assignment which would have been trivial if anyone in the class knew that fts.h existed. > Never knew that one either. Not part of the C standard library I guess. fts(3) is a BSD interface. It got introduced in 4.3BSD-Reno.
- dfox 8y ago
  fts(3) is also in SuSv3, but last time I checked it was not available on Solaris (but that was like 10 years ago). More portable but more limited equivalent is ftw(3).
  - caf 8y ago

dfox 8y ago

Somewhat relevant fact is that almost any hosted environment (including MSVC) actually implements large subset of POSIX functions that are not part of C standard. And this does not only consist of OS interface functions but also of various general purpose userspace-only algorithms and data structures.

spc476 8y ago

The post was based up the book The Standard C Library by P. J. Plauger. It's an excellent reference (if a bit dated as it only covers C89) that not only prints the relevant bits from the C Standard, but goes into the history behind the functions and provides an implementation.