Newsgroups: comp.lang.c Path: utzoo!henry From: henry@utzoo.uucp (Henry Spencer) Subject: Re: fgetpos, fsetpos, and ANSIness in general Message-ID: <1989Oct9.064503.5260@utzoo.uucp> Organization: U of Toronto Zoology References: Date: Mon, 9 Oct 89 06:45:03 GMT In article otto@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@zoo.toronto.edu