Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!think!ima!haddock!karl
From: karl@haddock
Newsgroups: net.lang.c
Subject: Re: fgets() returns NULL at EOF??
Message-ID: <86900038@haddock>
Date: Wed, 3-Sep-86 15:35:00 EDT
Article-I.D.: haddock.86900038
Posted: Wed Sep  3 15:35:00 1986
Date-Received: Wed, 3-Sep-86 21:55:43 EDT
References: <1094@bu-cs.bu-cs.BU.EDU>
Lines: 16
Nf-ID: #R:bu-cs.bu-cs.BU.EDU:1094:haddock:86900038:000:792
Nf-From: haddock!karl    Sep  3 15:35:00 1986


bzs@bu-cs.BU.EDU (Barry Shein) writes:

>Traditionally, any function that cannot return a promised pointer ...
>returns NULL (there exists a few syscalls which return ((char *) -1) or
>equivalent, c'est la vie, this has been hashed out, I guess the rule that
>syscalls return -1 won [eg. sbrk].)

Last time I used a pdp11, there was a bug in lseek().  The error return,
which should have been (long)-1 (i.e. 0xffffffff) was 0xffff0000.  I never
determined whether this was an AT&T standard bug or a local glitch.  The
surprising thing is that lseek *was* making the check, but it explicitly
set r1 (the lower half) to 0 instead of -1!  On systems where char* is wider
than int, sbrk() could have a similar problem.

Karl W. Z. Heuer (ima!haddock!karl; karl@haddock.isc.com), The Walking Lint