Sender: vheyndri AT rug DOT ac DOT be
Message-Id: <34CDA0C2.3089@rug.ac.be>
Date: Tue, 27 Jan 1998 09:54:26 +0100
From: Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
Mime-Version: 1.0
To: DJ Delorie <dj AT delorie DOT com>
Cc: andrewc AT rosemail DOT rose DOT hp DOT com, djgpp-workers AT delorie DOT com
Subject: Re: iostream concern
References: <199801270133 DOT UAA06134 AT delorie DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

DJ Delorie wrote:
> 
> Beware: in MS-DOS the file position may be negative.  At least, this
> is what I remember from our discussion of the portability of lseek()
> under "undefined" conditions.  Having a file position that doesn't
> allow for negative numbers, when MS-DOS will gladly give you a
> negative number, may cause obscure problems at runtime.

I'm not so sure whether DOS "allows" the file pointer to be negative. I
know that RBI tells me that it is allowed, but you could explain it as
easily as that the file pointer is silently overflowed when it passes
the 0 position. 
This duality probably arise from the fact that with SEEK_SET the offset
parameter is considered as absolute and with SEEK_REL and SEEK_END as
relative, and when calling DOS fn 42h they both end up in the same
register.
The fact that DOS always produced errors for "negative" offsets is
probably due to the fact that those offset are 2G+ and until recently
even no one ever could create such files (DOS 6.22- even does not allow
for them)

-- 
 \ Vik /-_-_-_-_-_-_/   
  \___/ Heyndrickx /          
   \ /-_-_-_-_-_-_/