errno strageness (in lpr)
Hi,
Following Marcus' message[1], I thought I'd have a look at lpr.
dh_testdir
pmake CFLAGS="-O2" CPPFLAGS="-D_BSD_SOURCE"
all ===> lpc
all ===> lpd
cc -o lpd lpd.o printjob.o recvjob.o displayq.o rmjob.o
startdaemon.o lpdchar.o common.o key.o modes.o getcap.o
printjob.o: In function `printjob':
printjob.o(.text+0xfc): the use of `mktemp' is dangerous, better use
`mkstemp'
lpd.o: In function `main':
lpd.o(.text+0x16a): undefined reference to `__errno_location'
lpd.o(.text+0x5d1): undefined reference to `__errno_location'
lpd.o(.text+0x6ba): undefined reference to `__errno_location'
lpd.o: In function `reapchild':
lpd.o(.text+0x7e3): undefined reference to `__errno_location'
lpd.o(.text+0x80a): undefined reference to `__errno_location'
printjob.o(.text+0x1d6): more undefined references to
`__errno_location' follow
printjob.o: In function `sendmail':
printjob.o(.text+0x284b): undefined reference to `_IO_getc'
printjob.o: In function `opennet':
printjob.o(.text+0x339d): undefined reference to `__errno_location'
printjob.o: In function `opentty':
printjob.o(.text+0x34ad): undefined reference to `__errno_location'
collect2: ld returned 1 exit status
*** Error code 1
Stop.
*** Error code 1
Stop.
make: *** [build-stamp] Error 1
Here[2] Roland says '"errno" is a macro and cannot be used as a normal
variable or member name.'
So lets for example look at reapchild in lpd.c
static void
reapchild(signo)
int signo;
{
int status;
int save_errno = errno;
while (waitpid((pid_t)-1, &status, WNOHANG) > 0)
;
errno = save_errno;
}
Since it fails to compile I take it that this is an
unacceptable usage of errno as a modifiable lvalue. I intend to
change the declaration of save_errno to "extern int save_errno"
to fix this. Correct?
The problem of errno usage in main() I understand (even) less.
e.g:
if (errno == EWOULDBLOCK)
if (errno != EINTR)
I would have thought that these usages were OK. Apparently not.
Help?
Paul.
[1] http://lists.debian.org/debian-hurd-0106/msg00249.html
[2] http://lists.debian.org/debian-hurd-0102/msg00204.html
Reply to: