home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.sys.sun.misc:3309 comp.unix.ultrix:5860 comp.unix.bsd:2732
- Path: sparky!uunet!wupost!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!agate!ICSI.Berkeley.EDU!stolcke
- From: stolcke@ICSI.Berkeley.EDU (Andreas Stolcke)
- Newsgroups: comp.sys.sun.misc,comp.unix.ultrix,comp.unix.bsd
- Subject: Beware of fileno()
- Date: 24 Jul 1992 00:36:30 GMT
- Organization: International Computer Science Institute, Berkeley, CA, U.S.A.
- Lines: 29
- Distribution: world
- Message-ID: <14njaeINNvk@agate.berkeley.edu>
- NNTP-Posting-Host: icsib30.icsi.berkeley.edu
- Keywords: sunos, ultrix, stdio, fileno, lossage
-
- Hi,
-
- I was just wondering if I am the first one to hit upon this (I suspect not).
- I was debugging a program that uses lots of file descriptors, which
- started to elicit Bad file number errors for no obvious reasons.
-
- It turned out, the fileno() macro from stdio.h was to blame. If you do a
-
- FILE *stream = fopen(....);
- int d = fileno(stream);
-
- and you have used up all file descriptors up to 127, you're screwed.
- This is because fileno() returns a char field in the FILE structure.
- On systems like Sun where char is signed this results in a negative
- integer file descriptor. To prevent lossage, one has to use
-
- (unsigned char)fileno(stream)
-
- or explicitly mask the most significant bits off.
- The right solution, of course, would be to define the file number field
- as unsigned char to begin with.
-
- SunOS, Ultrix and MIPS RISC/os have the same problem, so I suspect it comes
- from BSD. Why has this never been fixed?
-
- --
- Andreas Stolcke stolcke@icsi.berkeley.edu
- International Computer Science Institute stolcke@ucbicsi.bitnet
- 1947 Center St., Suite 600, Berkeley, CA 94704 (510) 642-4274 ext. 126
-