NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/unix/ultrix/9003

Internet Message Format | 1992-12-21 | 1.7 KB

Path: sparky!uunet!spool.mu.edu!yale.edu!ira.uka.de!uka!news!hf
From: [e-mail] (Harald Fuchs)
Newsgroups: comp.unix.ultrix
Subject: Inconsistent behavior of ioctl(FIONREAD)
Date: 21 Dec 92 12:03:51
Organization: Karlsruhe University, Germany
Lines: 28
Message-ID: <[e-mail]>
NNTP-Posting-Host: whyaduck.telematik.informatik.uni-karlsruhe.de

While integrating slow data sources like ttys or sockets into a
homemade lightweight process package I noticed a strange behavior
of ioctl(FIONREAD).

Basically, I do the following:
1) Set the file descriptor to nonblocking and asynchronous with
   ioctl(FIONBIO) resp. ioctl(FIOASYNC)
2) When Ultrix hits me with a SIGIO, I do a select() with timeout=0
3) For all descriptors in the returned rmask, I want to know if there
   has anything happened *without trying to read* from them. So I do
   ioctl(FIONREAD).

This works fine so far, but there is a problem with EOF. When I get
EOF on a tty, Ultrix sends me a SIGIO (as it should), select() sets
the corresponding descriptor in the rmask (as it should), and
ioctl(FIONREAD) returns 1. With sockets, everything is the same except
that ioctl(FIONREAD) returns 0.
Returning 0 sounds reasonable since there are no more bytes to read.
Returning 1 sounds reasonable, too, since the fd has got the
information that it has reached eof, thus causing the next read() to
return without EWOULDBLOCK.
But I think the inconsistent behavior described above could be called
a bug. Unfortunately, I couldn't find anything in the documentation
about the return value of ioctl(FIONREAD) in case of eof. What do you
think?
--

Harald Fuchs <[e-mail]>