Red Hat Bugzilla – Bug 249723
sscanf(str, "%as", &charptr) broken with --std=gnu99
Last modified: 2007-11-30 17:12:11 EST
Description of problem:
the type checking for sscanf() doesn't allow "%as" when invoked with --std=gnu99.
Version-Release number of selected component (if applicable):
A patch is attached to this bug which I think correctly fixes this issue.
Created attachment 160047 [details]
this is a fix.
That code is intentional, glibc violates the C99 standard by this.
The upcoming POSIX standard will use m modified instead (so %ms, %mS, %mls, %m[)
and glibc will soon implement it. ATM I have a few questions about the exact
wording and unclear description of memory allocation failure handling case
(which will be different from glibc's %as/%aS/%a[ modifier handling), once
that's resolved we'll implement it in glibc and also in gcc format checking
(the m modifier letter has been cleared with ISO groups already).
Well, yeah, it's a gnu extension -- that's why --std is set to gnu99, not c99 or
similar. The current behavior is directly contrary to the current documentation.
But it is a GNU extension that violates the standard, -std=gnu99 generally
enables extensions to the standard that don't conflict with the standard.
The warning is still very useful to inform people about the extension conflict
with the standard.
When we implement the m modifier, the intent is for the strict modes to not
accept %as, %aS and %a[ any longer (have a separate set of *scanf entrypoints
for that mode) and people really should be aware of this.
Hopefully they will switch to using %ms, %mS, %m[ soon to get rid of the warning,
which is the intent.