Re: Anyone object to the following change in libc?

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 7.19.6.2.
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
brandt_at_fokus.fraunhofer.de, harti_at_freebsd.org