Re: Anyone object to the following change in libc?

On Tue, 28 Oct 2003, Daniel Eischen wrote:

DE>On Tue, 28 Oct 2003, Harti Brandt wrote:
DE>
DE>>
DE>> (Cc set to current).
DE>>
DE>> On Tue, 28 Oct 2003, Jordan K Hubbard wrote:
DE>>
DE>> JKH>Back in the pre-panther timeframe, we received the following bug report:
DE>> JKH>
DE>> JKH>Earlier versions of Mac OS X (e.g., 10.2.6) return a value of -1 with
DE>> JKH>the following program:
DE>> JKH>
DE>> JKH>#include <stdlib.h>
DE>> JKH>
DE>> JKH>main()
DE>> JKH>{   int ret, x;
DE>> JKH>     ret = sscanf ("123", "%*d%d", &x);
DE>> JKH>     printf("ret is %d\n", ret);
DE>> JKH>}
DE>> JKH>
DE>> JKH>On Panther, the return value is zero. It affects packages like GMP,
DE>> JKH>whose automated test sequence assumes that "-1" is the proper return
DE>> JKH>value.
DE>> JKH>
DE>> JKH>A little investigation revealed that FreeBSD had changed vfscanf()
DE>> JKH>about 6 years ago, but it was the only "Unix" to do so and everyone
DE>> JKH>else has stuck with the more traditional behavior of returning an error
DE>> JKH>in this case.  We've done some investigation and consulted SUSv3, but
DE>> JKH>it's unfortunately vague on what the "proper" behavior should be so it
DE>> JKH>seems that it's been left to the various implementations to decide for
DE>> JKH>themselves what constitutes correct behavior.  Given the fact that
DE>> JKH>FreeBSD appears to be the odd-man out, we plan to revert back to the
DE>> JKH>10.2.6 behavior for vfscanf() in 10.4, but it seems a pity to have
DE>> JKH>FreeBSD diverge here (not just from Mac OS X past and future but from
DE>> JKH>Linux and Solaris) in ways that break known 3rd-party software and for
DE>> JKH>reasons which remain obscure.
DE>> JKH>
DE>> JKH>So, two questions:
DE>> JKH>
DE>> JKH>1. Are the reasons not as obscure as I think?  I'd welcome an
DE>> JKH>explanation as to why this was done.
DE>>
DE>> I think ISO-C is pretty clear here. Basically three things happen when
DE>> the scanf() finds a format specifier: it matches the input string
DE>> according to the format specifier, if that match is not empty it converts
DE>> the value to the corresponding type and, if assignment suppression was
DE>> not specified it assigns the value.
DE>>
DE>> When applying "%*d%d" to the string "123" the first 'd' format matches
DE>> the string "123" and the conversion yields the number 123. This is then
DE>> thrown away because assignment is suppressed. The next format specified
DE>> finds an EOF condition on the stream so this counts as an input error
DE>> according to paragraph 9, last sentence of 7.19.6.2.
DE>>
DE>> According to to paragraph 18 ("The fscanf function returns the value of
DE>> the macro EOF if an input failure occurs before any conversion. Otherwise,
DE>> the function returns the number of input items assigned, which can be
DE>> fewer than provided for, or even zero, in the event of an early matching
DE>> failure.") the function returns 0, because there was a succesful
DE>> conversion but no assignment.
DE>>
DE>> I just had a look at the v7 implementation. In this implementation a
DE>> suppressed assignment is not counted as a match even if the
DE>> match was successful. This explains the return of -1 if the first
DE>> not-suppressed conversion failes.
DE>>
DE>> I think changing current behaviour would be a regression with regard to
DE>> ISO-C (and Posix).
DE>
DE>I agree, and to add a little snippet of POSIX:
DE>
DE>  RETURN VALUE
DE>
DE>    Upon successful completion, these functions shall return the
DE>    number of successfully matched and assigned input items; this
DE>    number can be zero in the event of an early matching failure.
DE>    If the input ends before the first matching failure or
DE>    conversion, EOF shall be returned. If a read error occurs, the
DE>    error indicator for the stream is set, EOF shall be returned,
DE>    and errno shall be set to indicate the error.
DE>
DE>There is no matching failure, but there is a conversion.  I think
DE>"%*d" just counts as an assignment suppression but does not suppress
DE>the fact that a conversion occurred.
DE>
DE>On the other hand, Solaris 8 does seem to return -1...

But Solaris 8 and 9 also don't understand 'hh' modifiers and therefor are
neither ISO nor Posix conform. While we have Solaris 10 here, we have yet
to install it somewhere.

harti
-- 
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
brandt_at_fokus.fraunhofer.de, harti_at_freebsd.org