Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: henry@utzoo.UUCP (Henry Spencer)
Newsgroups: comp.lang.c
Subject: Re: Distorting fseek semantics
Message-ID: <8570@utzoo.UUCP>
Date: Sat, 12-Sep-87 20:53:13 EDT
Article-I.D.: utzoo.8570
Posted: Sat Sep 12 20:53:13 1987
Date-Received: Sat, 12-Sep-87 20:53:13 EDT
References: <493@its63b.ed.ac.uk> <6061@brl-smoke.ARPA> <8560@utzoo.UUCP>
Organization: U of Toronto Zoology
Lines: 24

> SUMMARY:  The weakened fseek in ANSI C will lead to fewer vendors being
> pressured into providing the more flexible UNIX-style fseek, without a
> compensating gain in portability.  Users will lose.

(I am resisting the temptation of a blow-by-blow answer to the whole
100-line article...)  Repeat after me:  "the purpose of standards committees
is to standardize existing practice, not to try to force goodness and truth
down everyone's throats".  The fact is, existing practice -- in the C
community as a whole rather than the somewhat bigoted and self-centered
Unix subset of it -- is exactly what is being codified in ANSI C.  It has
*never* been true that a portable program could assume full Unix fseek
semantics.  And trying to force all manufacturers to do a Unix-compatible
fseek is just as likely to be a loss for the users, because it will hamper
wide acceptance of the ANSI standard.

> **The only exception I know of, where a vendor did not use the UNIX
> standard as a model...

There are a lot more exceptions than the one you cite; this merely reflects
your limited experience, I'm afraid.  Most vendors would *like* to make
their fseek Unix-compatible, but not all can.
-- 
"There's a lot more to do in space   |  Henry Spencer @ U of Toronto Zoology
than sending people to Mars." --Bova | {allegra,ihnp4,decvax,utai}!utzoo!henry