fgetpos, fsetpos, and ANSIness in general

[Otto J. Makela]

Here I go again, braving all the flames of the whole network...

While leafing thru the "C Programming Language, 2nd Edition", I stumbled across
the two functions fgetpos and fsetpos.  Now, the minimalist description given
in the book seem to indicate the same functionality as ftell and fseek, with
slightly different argument types.  What gives ?

In general, I've come to the same conclusion as a friend: "Seems the ANSI thing
has several changes just to make life difficult for traditional Unix C users."
Many of the "features" are truly bizarre (think about #) and there is a real
danger of creeping Pascalism (now that was a nasty thing to say -- should I
crosspost to alt.religion.computers ? :-)

For example, I like the idea behind strftime, the date formatting routine ala
printf.  But I dislike the interface: the more-or-less Unix tradition for such
functions is to return a pointer to a fixed buffer.  All right, all kinds of
things can (and have) been said of this type of implementations, but I would
claim that in general, it makes for simpler, no-hassles programming.

Now, this interface could be extended for this: define that the function will
use a internal buffer of, er, let's say 80 characters IF the buffer pointer
given is NULL.  Function returns zero, as originally, if the buffer length is
exceeded.  This way, you get the best of both implementation ideas.  Nothing
like this was not done.  Why ?

Could someone point me to a good book ala K&R 2nd Ed. which would go into
the library description in a bit more detail ?  I'd prefer not to dig into
the actual ANSI committee stuff on it, but something a bit more digested.
Email please on this last.  Flames must (of course :-) be posted...
--
* * * Otto J. Makela (otto at jyu.fi, MAKELA_OTTO_ at FINJYU.BITNET) * * * * * * *
* Phone: +358 41 613 847, BBS: +358 41 211 562 (CCITT, Bell 2400/1200/300) *
* Mail: Kauppakatu 1 B 18, SF-40100 Jyvaskyla, Finland, EUROPE             *
* * * freopen("/dev/null","r",stdflame); * * * * * * * * * * * * * * * * * *