curnutt@psu-cs.UUCP (04/16/87)
Other Organization: Store Systems Information, Portland, Oregon Keywords: In article <143@sds.UUCP> dave@sds.UUCP (dave schmidt x194) writes: > >I just found a nasty problem with lex on Microsoft XENIX System V; > . [description of lex input() sometimes failing with error ENOTTY ] [(Not a typewriter)] . >Has anyone seen or heard of anything similiar? We're using SCO Xenix on a Sperry IT, and I've found that fprint(), when used with text files, will always set errno to ENOTTY and return a non-zero value. What makes this more interesting is that the fprintf() DOES WORK. I called SCO about this, and they told me to ignore it. Bryan "Well, it's better than DOS" Curnutt
chris@mimsy.UUCP (Chris Torek) (04/17/87)
In article <415@psu-cs.UUCP> curnutt@psu-cs.UUCP (Bryan Curnutt) writes: >We're using SCO Xenix on a Sperry IT, and I've found that fprintf(), >when used with text files, will always set errno to ENOTTY and return >a non-zero value. What makes this more interesting is that the >fprintf() DOES WORK. I called SCO about this, and they told me >to ignore it. They are right, for this is not a bug. In System V, fprintf returns the number of characters written, `or a negative value if an output error was encountered'. C library (manual section 3) routines, unless otherwise specified, do not promise anything about `errno'. It is not correct to use errno even if fprintf returns an error indication (although it may be better than nothing). -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) UUCP: seismo!mimsy!chris ARPA/CSNet: chris@mimsy.umd.edu