fgetpos, fsetpos, and ANSIness in general

[Doug Gwyn]

In article <OTTO.89Oct8093607 at tukki.jyu.fi> otto at tukki.jyu.fi (Otto J. Makela) writes:
>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 ?

The f*etpos() functions communicate file positions with cookies, while the
traditional fseek()/ftell() communicate them as long integers (byte offsets,
for binary streams).  Cookies are needed because many systems support files
containing more bytes than can be represented in the natural size for a
long integer.  You don't have to use the new f*etpos() functions unless your
program needs to randomly access huge files.  Few applications do.

>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."

Maybe you shouldn't draw conclusions based on insufficient information.
That's an utterly fantastic notion; what makes life "difficult for
traditional UNIX C programmers" is their ignorance of the differences
between UNIX and more general computing contexts.  Those differences
cannot be ignored in a non UNIX-specific programming language standard.

>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 ? :-)

There is nothing particularly bizarre about the # preprocessing operator.
It could have been spelled differently, and there were several alternative
proposals for obtaining the same functionality in different ways, but nobody
seriously challenged the practical need for such a "stringizing" operator,
as evidenced by a large body of existing code that exploited a misfeature
of Reiser's cpp to effect argument substitution within string literals.

I don't know what "Pascalism" is supposed to consist of.  Practically all
Pascal-inspired proposals for extensions or changes to C were rejected.

>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.

Other experienced programmers do not agree with you.  There are several
mistakes in the "UNIX tradition"; one should learn from them instead of
mimicking them.

>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 ?

We like our design better, that's why.  Why add complexity?

>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.

"Standard C" by P. J. Plauger and Jim Brodie (1989, Microsoft Press),
ISBN 1-55615-158-6.