Re: Anyone object to the following change in libc?

Harti Brandt wrote:
> When applying "%*d%d" to the string "123" the first 'd' format matches
> the string "123" and the conversion yields the number 123. This is then
> thrown away because assignment is suppressed. The next format specified
> finds an EOF condition on the stream so this counts as an input error
> according to paragraph 9, last sentence of 7.19.6.2.
> 
> According to to paragraph 18 ("The fscanf function returns the value of
> the macro EOF if an input failure occurs before any conversion. Otherwise,
> the function returns the number of input items assigned, which can be
> fewer than provided for, or even zero, in the event of an early matching
> failure.") the function returns 0, because there was a succesful
> conversion but no assignment.

Paragraph 6 of:

	http://www.opengroup.org/onlinepubs/007904975/functions/sscanf.html

Implies that the lack of characters in the string following the
conversion, due to failure in assignment, should result in an
"Input failure".  Note also that stdio.h defines EOF as -1.

I think it can be interpreted either way, still.


> I just had a look at the v7 implementation. In this implementation a
> suppressed assignment is not counted as a match even if the
> match was successful. This explains the return of -1 if the first
> not-suppressed conversion failes.
> 
> I think changing current behaviour would be a regression with regard to
> ISO-C (and Posix).

I really hate the idea of "conforming to Linux"; if I wanted to
run Linux, I'd run Linux.

On the other hand, there's a lot to be said for least common
denominator, and it's not like Linux' "great idea" of updating
the select struct timeval here: pretty much everyone has the
same behaviour as Linux, which is to say, -1.

I think with a suppressed assignment, it's simply not possible
to distinguish an error return from an EOF return, which really
makes me tempted to say "return -1".

-- Terry