On Tue, 28 Oct 2003, Terry Lambert wrote: TL>Harti Brandt wrote: TL>> When applying "%*d%d" to the string "123" the first 'd' format matches TL>> the string "123" and the conversion yields the number 123. This is then TL>> thrown away because assignment is suppressed. The next format specified TL>> finds an EOF condition on the stream so this counts as an input error TL>> according to paragraph 9, last sentence of 220.127.116.11. TL>> TL>> According to to paragraph 18 ("The fscanf function returns the value of TL>> the macro EOF if an input failure occurs before any conversion. Otherwise, TL>> the function returns the number of input items assigned, which can be TL>> fewer than provided for, or even zero, in the event of an early matching TL>> failure.") the function returns 0, because there was a succesful TL>> conversion but no assignment. TL> TL>Paragraph 6 of: TL> TL> http://www.opengroup.org/onlinepubs/007904975/functions/sscanf.html TL> TL>Implies that the lack of characters in the string following the TL>conversion, due to failure in assignment, should result in an TL>"Input failure". Note also that stdio.h defines EOF as -1.
I fail to locate this paragraph. This interpretation would also imply that scanf() always needs to return -1 whenever it cannot match a format specifier. TL> TL>I think it can be interpreted either way, still. You miss the section about RETURN VALUE: EOF is return on a read error. This is not an input error. You should also read the very 1st paragraph. This clearly states, that ISO is the primary source of information and the ISO text is a lot cleaner. TL> TL> TL>> I just had a look at the v7 implementation. In this implementation a TL>> suppressed assignment is not counted as a match even if the TL>> match was successful. This explains the return of -1 if the first TL>> not-suppressed conversion failes. TL>> TL>> I think changing current behaviour would be a regression with regard to TL>> ISO-C (and Posix). TL> TL>I really hate the idea of "conforming to Linux"; if I wanted to TL>run Linux, I'd run Linux. TL> TL>On the other hand, there's a lot to be said for least common TL>denominator, and it's not like Linux' "great idea" of updating TL>the select struct timeval here: pretty much everyone has the TL>same behaviour as Linux, which is to say, -1. TL> TL>I think with a suppressed assignment, it's simply not possible TL>to distinguish an error return from an EOF return, which really TL>makes me tempted to say "return -1". I think it makes no sense to classify sscanf("123", "%*d%d", ... as an error, but sscanf("123", "%d%d", ... not, does it? Also at least Solaris 9 return -1 but fails to set errno. Which is simply a bug. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"