Date: Tue, 28 Oct 2003 12:01:32 +0100 (CET) From: Harti Brandt <brandt@fokus.fraunhofer.de> To: Jordan K Hubbard <jkh@queasyweasel.com> Cc: current@FreeBSD.org Subject: Re: Anyone object to the following change in libc? Message-ID: <20031028113626.A23296@beagle.fokus.fraunhofer.de> In-Reply-To: <BAEB9CED-091F-11D8-B483-000393BB9222@queasyweasel.com> References: <BAEB9CED-091F-11D8-B483-000393BB9222@queasyweasel.com>
next in thread | previous in thread | raw e-mail | index | archive | help
(Cc set to current).
On Tue, 28 Oct 2003, Jordan K Hubbard wrote:
JKH>Back in the pre-panther timeframe, we received the following bug report:
JKH>
JKH>Earlier versions of Mac OS X (e.g., 10.2.6) return a value of -1 with
JKH>the following program:
JKH>
JKH>#include <stdlib.h>
JKH>
JKH>main()
JKH>{ int ret, x;
JKH> ret = sscanf ("123", "%*d%d", &x);
JKH> printf("ret is %d\n", ret);
JKH>}
JKH>
JKH>On Panther, the return value is zero. It affects packages like GMP,
JKH>whose automated test sequence assumes that "-1" is the proper return
JKH>value.
JKH>
JKH>A little investigation revealed that FreeBSD had changed vfscanf()
JKH>about 6 years ago, but it was the only "Unix" to do so and everyone
JKH>else has stuck with the more traditional behavior of returning an error
JKH>in this case. We've done some investigation and consulted SUSv3, but
JKH>it's unfortunately vague on what the "proper" behavior should be so it
JKH>seems that it's been left to the various implementations to decide for
JKH>themselves what constitutes correct behavior. Given the fact that
JKH>FreeBSD appears to be the odd-man out, we plan to revert back to the
JKH>10.2.6 behavior for vfscanf() in 10.4, but it seems a pity to have
JKH>FreeBSD diverge here (not just from Mac OS X past and future but from
JKH>Linux and Solaris) in ways that break known 3rd-party software and for
JKH>reasons which remain obscure.
JKH>
JKH>So, two questions:
JKH>
JKH>1. Are the reasons not as obscure as I think? I'd welcome an
JKH>explanation as to why this was done.
I think ISO-C is pretty clear here. Basically three things happen when
the scanf() finds a format specifier: it matches the input string
according to the format specifier, if that match is not empty it converts
the value to the corresponding type and, if assignment suppression was
not specified it assigns the value.
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.
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).
harti
--
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
brandt@fokus.fraunhofer.de, harti@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031028113626.A23296>