This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Use C99-compliant scanf under _GNU_SOURCE with C99/C++11 and higher.
- From: Florian Weimer <fweimer at redhat dot com>
- To: Zack Weinberg <zackw at panix dot com>
- Cc: libc-alpha at sourceware dot org, adhemerval dot zanella at linaro dot org
- Date: Mon, 17 Dec 2018 18:00:56 +0100
- Subject: Re: [PATCH] Use C99-compliant scanf under _GNU_SOURCE with C99/C++11 and higher.
- References: <20181217161827.12154-1-zackw@panix.com>
* Zack Weinberg:
> +* An archaic GNU extension to scanf, under which '%as', '%aS', and '%a[...]'
> + meant to scan a string and allocate space for it with malloc, is now
> + restricted to programs compiled in C89 or C++98 mode with _GNU_SOURCE
> + defined. This extension conflicts with C99's use of '%a' to scan a
> + hexadecimal floating-point number, which is now available to programs
> + compiled as C99 or C++11 or higher, regardless of _GNU_SOURCE.
> +
> + POSIX.1-2008 includes the feature of allocating a buffer for string input
> + with malloc, using the modifier letter 'm' instead. Programs using
> + '%as', '%aS', or '%a[...]' with the old GNU meaning should change to
> + '%ms', '%mS', or '%m[...]' respectively. Programs that wish to use the
> + C99 '%a' no longer need to avoid _GNU_SOURCE.
> +
> + GCC's -Wformat warnings can detect most uses of this extension, as long
> + as all functions that call vscanf, vfscanf, or vsscanf are annotated with
> + __attribute__ ((format (scanf, ...))).
What's the state of GCC warnings? Does GCC already anticipate this
change?
Thanks,
Florian