From: nxk3 AT dante DOT student DOT cwru DOT edu (Natarajan Krishnaswami) Newsgroups: comp.os.msdos.djgpp Subject: Re: ISO "C" violation. Date: 9 Feb 1997 14:43:32 GMT Organization: Case Western Reserve University, Cleveland OH (USA) Lines: 37 Message-ID: References: <19970208 DOT 183318 DOT 4231 DOT 0 DOT stodmaster AT juno DOT com> Reply-To: nxk3 AT dante DOT cwru DOT edu NNTP-Posting-Host: dante.student.cwru.edu Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp On Sat, 8 Feb 1997 23:34:41 GMT, Joshua M Beall wrote: > I have DJGPP for the IBM PC, and have noted that fscanf returns > NULL, however, I cannot find a single ISO "C" reference book that > indicates it should do so. Perhaps one should not say NULL (i.e., (void*)0) but (int)0. (From linux fscanf(3) man page) These functions return the number of input items assigned, which can be fewer than provided for, or even zero, in the event of a matching failure. Zero indicates that, while there was input available, no conversions were assigned; typically this is due to an invalid input character, such as an alphabetic character for a `%d' conversion. The value EOF is returned if an input failure occurs before any conversion such as an end-of-file occurs. If an error or end-of-file occurs after conversion has begun, the num- ber of conversions which were successfully completed is returned. (From 'fprintf.c' from DJGPP library source) return ferror(iop) ? EOF : len; This appears to be analogous. EOF is returned if there is an error on reading input, otherwise, a length is returned. Linux fprintf claims ANSI C3.159-1989 conformance with this behaviour, so I would surmise that djgpp's fprintf is also conformant. TTYL, N. -==(UDIC)==- "Als Gregor Samsa eines Morgens aus unruhigen Träumen erwachte, fand er sich in seinem Bett zu einem ungeheueren Ungeziefer verwandelt." -Franz Kafka, "Die Verwandlung"