fgetpos, fsetpos, and ANSIness in general

[Henry Spencer]

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 slightly-different argument types are important, and are the whole
reason for those functions.  The crucial observation is that a 32-bit
number is no longer big enough for a file offset -- people with big
databases think nothing of files several gigabytes long.  Fixing fseek
and friends is impossible; the backward-compatibility hassles would be
beyond belief.  Fgetpos and fsetpos are versions that can use a larger
type if necessary.

>Many of the "features" are truly bizarre (think about #) ...

Some of us prefer not to think about #.  Its only saving grace is that it's
better than the awful undocumented implementation-specific kludges that it
replaces.  (You thought X3J11 made up the whole concept?  Ho ho.  Wrong.)
(Some of us think they should have buried it with a stake through its
heart, but that's another debate.)

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

Unfortunately, that traditional interface causes a *lot* of problems and
there are good reasons to try to avoid it.  Especially for things that can
generate potentially-unlimited amounts of data.

>[proposed alternative] Nothing like this was not done.  Why ?

Probably because there was implementation experience with strftime as it
is (no, X3J11 didn't make it up) and there wasn't any with your alternative.
For all the nasty things that have been said about X3J11, *very* few of the
things in the final draft standard were invented from scratch; almost all
of it has been implemented, and found workable, somewhere.  The few real
inventions, in fact, are generally the most controversial parts.

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

(I'm posting this rather than emailing because I think it's of general
interest.)  Believe it or not, the ANSI drafts are generally highly readable
and not at all hard to follow.  If you find K&R2 manageable, you should be
able to read an ANSI C draft without trouble.  There are a few areas of the
language itself where you have to read very carefully and legalistically,
but I don't recall anything like that in the library section.

You might try Harbison&Steele, 2nd ed, although it probably needs updating
to match the latest ANSI draft by now.
-- 
A bit of tolerance is worth a  |     Henry Spencer at U of Toronto Zoology
megabyte of flaming.           | uunet!attcan!utzoo!henry henry at zoo.toronto.edu