I'm finding it really hard to keep some of these things straight...
For example, fputs is to puts as fprintf is to printf, except that
fputs has the file handle at the end and fprintf at the beginning!
Very illogical! And hard to remember.
Yes, it's inconsistent, but with practice you'll find
it is not hard to remember. Not for the functions you use
frequently, anyhow: I confess that despite thirty-plus years
of programming in C the order of the arguments to bsearch()
still eludes me (I scarcely ever use it), and I still get
confused about the middle two arguments to fread() and
fwrite(). But that's never bothered me much, because on
the occasions when I want to use one of these functions I
just look them up in any convenient reference: man page,
info screen, or even (gasp!) a book printed on paper. It's
not difficult.
To understand the reason for the inconsistencies, you
must realize that the C library did not spring full-armed
from the brow of Jove. It was not invented by one person,
at one place, or even at one time, but evolved over a span
of years at many places, with people borrowing ideas they'd
seen elsewhere and "improving" on them in assorted (sometimes
incompatible) ways. The library as it stands today is a
fusion of multiple different libraries with various styles
and various levels of rigor.
Evolution is like that -- or haven't you thought about
your vermiform appendix lately?
Now this can quite easily be corrected by macros, for example:
#include <stdio.h>
#define fputs(X,Y) fputs(Y,X)
You need to start with `#undef fputs' to guard against
the possibility that <stdio.h> has already defined `fputs'
as a macro.
But oh, dear Lord, sweet Jesus, don't do this, I beg!
If you simply *must* introduce macros to arrange things to
your liking, at least give them names that don't look like
something else! Your code will be completely unreadable,
and (you will discover) unreadable code tends to acquire
an unusually high density of bugs -- and then turn out to
be unmaintainable. When you write code you will be writing
in a private language nobody else understands -- and you
will also find your own ability to read the common language
diminished. If you cannot live without your silly macro,
at least have the decency to call it `BFTSPLX'.
main() /* note: returning int not void!! */
("But not for long!" -- Sweeney Todd) Under the new
"C99" version of the Standard, it is illegal to omit the
type. Typing "eye enn tee space" saves keystrokes, compared
to the comment you had to type to defend its omission.
{
fprintf((FILE *) stdout, "A test\n");
Useless cast, since `stdout' is already a `FILE*'. Or,
to put it another way, why didn't you write
fprintf((FILE *)stdout, (char*)"A test\n");
fputs((FILE *) stderr, "Another test\n"); /* consistency reigns! */
Again, `stderr' is already a `FILE*'.
return 0;
}
So basically I was planning to build up a list of macro definitions to
regulate whatever inconsistencies I come through in stdlib, then I can
put them in a header to be #included in all my programs. But surely
other people will already have done this, so I thought I'd ask if any
such list is available somewhere before reinventing the wheel.
Nobody in his right mind has done such a thing, I am sure.
Invent your wheel if you must; I am sure it will roll you
straight to Perdition.
"A foolish consistency is the hobgoblin of little minds,
Adored by little statesmen and philosophers and divines."
-- Ralph Waldo Emerson
"That leg's long enough; pull on the other."
-- Anonymous