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
> 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:


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
[EMAIL PROTECTED] mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to