Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 15 Jul 1999 11:17:54 -0500
From:      Dan Nelson <dnelson@emsphone.com>
To:        James Bailie <jazzturk@home.com>
Cc:        freebsd-questions@FreeBSD.ORG
Subject:   Re: fseek() over bounds of file
Message-ID:  <19990715111754.A12473@dan.emsphone.com>
In-Reply-To: <19990715013023.A3264@cr31617-a.lndn1.on.wave.home.co>; from "James Bailie" on Thu Jul 15 01:30:23 GMT 1999
References:  <19990715013023.A3264@cr31617-a.lndn1.on.wave.home.co>

next in thread | previous in thread | raw e-mail | index | archive | help
In the last episode (Jul 15), James Bailie said:
> I'm a Linux refugee who has been running FreeBSD for about a week now
> and am extremely pleased with the system. In porting some software
> over, I've encountered a few differences from glibc2 I'd like some
> info on, that I don't remember seeing under Linux. Well, just one for
> now. I'm running 3.2-RELEASE, as anoncvs appears to be broken, that
> is to say it isn't anonymous, an (unknown to me) password is
> required, and judging from the date of a couple unanswered complaints
> on the mailing lists and newsgroups, has been broken for about three
> weeks! Correct me if I'm wrong here, it seems unlikely the service
> could go down for so long without more people than this noticing, but
> I far as I can tell, it is. So, I cannot check to see if the
> following behaviour persists in 3.2-CURRENT:

Most people don't use anoncvs afaik; they use cvsup which is immensely
faster.
 
> fseek() will not only seek past the end of a file, but will also seek
> backwards (negative offset) past the beginning of a file. The next
> file access fails instead of the call to fseek(). Is there some kind
> of way to make a hole in a file by seeking backwards I am unaware of,
> or is this a bug?  Also, fseek()-ing out of file boundaries, in
> either direction, succeeds, in the sense that the call returns zero,
> if the file has been opened read-only, which, in my opinion, it
> shouln't.

You could certainly argue that seeking to a negative position should
return [EINVAL]; the Single UNIX Specification actually wants this:

   [EINVAL]
          The whence argument is invalid. The resulting file-position
          indicator would be set to a negative value.

Seeking past the end-of-file is still allowed:

     The fseek() function allows the file-position indicator to be set
     beyond the end of existing data in the file. If data is later
     written at this point (possibly by another process), subsequent
     reads of data in the gap will return bytes with the value 0 until
     data is actually written into the gap.

Feel free to submit a PR with patches to fix the negative offset
problem :)
 
	-Dan Nelson
	dnelson@emsphone.com


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990715111754.A12473>