[issue17547] "checking whether gcc supports ParseTuple __format__... " erroneously returns yes with gcc 4.8

[Dave Malcolm]

Dave Malcolm added the comment:

On Wed, 2013-04-24 at 10:48 +0000, Alex Leach wrote:
> Alex Leach added the comment:
> 
> I don't think I can tell you anything you don't know already, but ...
> 
> On Tue, 23 Apr 2013 19:38:18 +0100, Dave Malcolm <report at bugs.python.org>  
> wrote:
> 
> > BTW, is that GCC format checking code available anywhere?
> 
> Is this what you mean?
> 
> http://gcc.gnu.org/viewcvs/gcc/trunk/gcc/c-family/c-format.c?annotate=193304&pathrev=193304
> 
> I got taken straight there from the link you sent, above...

[snip]

> Am I right in thinking that it was an out-of-tree patch to GCC, from
the
> > pre-plugin days?
> 

Sorry that I was a bit vague.

GCC's __attribute((format(i, j, k))__ takes 3 parameters.  The first
parameter is a string code naming the mini-language expressing valid
format strings and their mapping to the types that follow in the
varargs.

I was asking about the string code "PyArg_ParseTuple" used in the
CPython configure test: the link above is the implementation of GCC's
builtin format string codes: and AFAIK the only ones it "knows" about
there are the ones in 
   static const format_kind_info format_types_orig[] =
in the above file (lines 808-873 of gcc/c-family/c-format.c)

which are codes for printf, fprintf, various internal gcc APIs,
NSString, scanf, strftime, and strfmon.

i.e. I believe that the "PyArg_ParseTuple" code is from some 3rd party
patch to GCC that never made it into GCC mainline.  Does this code still
exist anywhere?

[Not that this has any bearing on this bug and the proposed patch: I'm a
big fan of compiler attributes, and wouldn't want to remove them from
the API.]

Hope the above makes sense

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17547>
_______________________________________