Re: on the irresponsibility of pursuing C language reform

[scs@eskimo.com (Steve Summit)]

I'm just a lurker, but let me offer my perspective on this.

Header files in C and C++ are in large part a nuisance and a
historical relic.  If I call function x, I must include header
<y.h>.  The mapping between x and y is partly sensible, but
partly arbitrary.

Since I program in C and/or C++ every day, I can usually remember
that mapping, but when I can't, I immediately check the man page,
and I'm glad that (unlike in the old days) the Synopsis section
always reminds me which header to include.

Although I said header files are a nuisance, in one key respect
they're less of a nuisance than they used to be, because *the C
and C++ standards standardize them*.  This is a huge, huge win.
Back in the day you never knew if you could or should use
reasonable-looking headers like <memory.h> or <malloc.h>.  But
today, it's a no-brainer.  There's one right answer.  If I use
the Standard header in my code, and my code fails to compile
under some brain-dead compiler tomorrow, it's that compiler's
fault, not mine.  I don't care a bit whether the Standard's
mappings do or don't make sense; the fact that they're standard
trumps anything else.

Now, this is one man's perspective, and I concede that I'm not
an average C or C++ programmer, either.  Me, I could check the
Standard, because I have PDF copies of every version of the C
Standard right here on my laptop, but for this sort of question I
typically don't, because typing "man memset" is so much quicker.
I don't know what the average programmer does, but I would
heartily advocate for a high-quality man page to give the Right
answer, where the Right answer for standard functions is
precisely what the Standard says.

Now, there are always interesting arguments to be had about which
of the library functions still hold their weight today, which of
them might be deprecated or replaced with something newer, and
how to educate users about evolving best practices.  Certainly,
today, strncpy and strncat are the new gets.  (As it happens,
I've been spending real time just in the past few weeks coping
with the fact that not every Linux C compiler I use ships with
a glibc that supports strlcpy and strlcat.)

But with that said, the place for those "interesting arguments"
is not a man page!  Man pages are supposed to be maximally
pithy.  Just the facts, ma'am.

Finally, I really don't think that the the mapping between
function x and header <y.h>, a mapping which I characterized as
somewhat arbitrary, is something that the average programmer pays
that much attention to.  If strncpy or memset is to be found in
a header called <string.h>, that doesn't tell us that these
functions operate on strings, any more than ssprintf appearing in
<stdio.h> implies that ssprintf does I/O.  So let's put the
arguing, and the opinionating, and the educating, somewhere else,
and have the man pages document (nay, recommend) precisely the
headers that the Standard(s) say are standard.

Steve Summit