Date: Tue, 26 Dec 2000 17:57:40 -0500
Message-Id: <200012262257.RAA24655@envy.delorie.com>
X-Authentication-Warning: envy.delorie.com: dj set sender to dj AT envy DOT delorie DOT com using -f
From: DJ Delorie <dj AT delorie DOT com>
To: djgpp-workers AT delorie DOT com
In-reply-to: <9003-Tue26Dec2000184539+0200-eliz@is.elta.co.il>
Subject: Re: An implementation of /dev/zero for DJGPP
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1001225105646 DOT 18547E-100000 AT is> <3A489766 DOT 349B3C71 AT bigfoot DOT com> <9003-Tue26Dec2000184539+0200-eliz AT is DOT elta DOT co DOT il>
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


> > Unfortunately /dev/zero's man page (FYI zero(4)) does not mention these
> > functions.
> 
> Well, you could write a short test program to see what GNU/Linux
> does.  We could also say we don't care ;-)

We care, but only enough to know that the results are well-defined.
Returning a fixed value in all cases is sufficient.

> > read() does not have to return the number of bytes asked for.
> 
> It doesn't?  I've seen gobs of programs which depend on the fact it
> does.

It doesn't.  It returns the number of bytes read, not the number you
asked for.  They don't have to match.  Network sockets are *notorious*
for returning less than you asked for.  So is stdin.  A temporary EOF
causes this also (i.e. someone else writes to the file while you're
reading from it).

> > So, when >= INT_MAX is requested, it will
> > return INT_MAX. Since the programmer should be aware that read() may not
> > return everything asked for, this avoids the overflow problem.
> 
> I don't think it's a good idea.  I also don't see any reason for such
> a drastic change in behavior, just to prevent buggy programs from
> getting what they asked for.

We have machines with more than 2G of memory running djgpp?