Bug#155835: libc6-dev: scanf a flag conflicts with C99
At Sun, 19 Dec 2004 18:44:16 +0200,
Antti-Juhani Kaijanaho wrote:
> On 20041220T013000+0900, GOTO Masanori wrote:
> > "%as" is GNU extension. Why don't you want to use "%a" instead of
> > "%as"? Note that C99 defines "%a" as signed floating-point number,
> > not modifier flag like l,L. Or am I missing something?
>
> That is exactly the problem. In C99 mode %as means %a followed by a
> literal s and thus cannot be interpreted as the GNU extension.
>
> (I'm a little puzzled by why GNU allowed the standard committee to
> introduce such a nasty incompatibility, but that's neither here nor
> there.)
Yes, it's problem. Another flags are ' and I.
Gcc -std=c99 warns because it's not part of C99 behavior. Glibc team
also recognized this problem. Unfortunatelly debian glibc does not
provide CONFORMANCE file in glibc (I think it's nice to add in future
version), but it says:
Defects in the C99 standard
===========================
Some defects in C99 were corrected in Technical Corrigendum 1
to that standard. glibc follows the corrected specification.
Implementation of library functions
===================================
The implementation of some library functions does not fully
follow the standard specification:
C99 added additional forms of floating point constants
(hexadecimal constants, NaNs and infinities) to be recognised
by strtod() and scanf(). The effect is to change the behavior
of some strictly conforming C90 programs; glibc implements the
C99 versions only irrespective of the standard version
selected.
C99 added %a as another scanf format specifier for floating
point values. This conflicts with the glibc extension where
%as, %a[ and %aS mean to allocate the string for the data
read. A strictly conforming C99 program using %as, %a[ or %aS
in a scanf format string will misbehave under glibc.
I also think another problem is scanf() may overflow the target buffer
when %s is used; it's standard fault. I guess GNU extension is
provided to change this standard "bug" for convenience.
I think these extensions should be removed in the future glibc
(because of your concern about "%a followed by a literal s". But once
it's removed, some programs may not work for it. One way to fix is to
check -D_GNU_SOURCE, and when it's designated, special scanf is called
to parse %a, %' and %I.
> > Note that if you want to select the glibc's definition behavior,
> > _D_ISOC99_SOURCE and so on can be used explicitly. See info libc.
^
-D_ISOC99_SOURCE
> I assume it's a GCC bug that it does not define that when --std=c99 is
> used? If so, feel free to reassign (assuming that defining
> _D_ISOC99_SOURCE really does make libc use C99 semantics for %as).
I don't think so.
> Note that there is no requirement in the C99 standard that
> _D_ISOC99_SOURCE be defined in C99 compilation units.
It's implementation dependent behavior to select standards compliance.
Glibc can switch between various standards. Read info libc.
Regards,
-- gotom
Reply to: