[Bug c/47781] New: warnings from custom printf format specifiers

[Bug c/47781] New: warnings from custom printf format specifiers

[mark-gcc at glines dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781

           Summary: warnings from custom printf format specifiers
           Product: gcc
           Version: 4.4.5
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: mark-gcc@glines.org


Glibc allows a project to define custom printf conversions, via one of two
APIs: register_printf_function, and more recently, register_printf_specifier. 
For instance, my project has a custom %v conversion, which takes a pointer to a
vector structure that is heavily used within the project, and pretty-prints it.

The problem is, every time the custom format conversion is used, gcc (which is
invoked with -Wall) generates warnings.

test.c:198: warning: unknown conversion type character ‘v’ in format
test.c:198: warning: too many arguments for format

I can get rid of the warnings with -Wno-format, but that also disables the rest
of gcc's format string checking (which is very helpful!).

I'd like to request a finer grained means of control.  A syntactical element
(builtin/pragma/attribute/whatever) to pre-declare a format conversion and the
typedef to check it against would be very nice, if complex.  A much simpler
solution would be a -Wno-format-unknown-specifier option, which skips the
argument in the argument list and otherwise ignores conversions it doesn't
recognize.

Any solution along those lines would be very helpful.

[Bug c/47781] warnings from custom printf format specifiers

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu.org

--- Comment #1 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2011-02-17 11:57:54 UTC ---
Which project is this?

I think a patch that adds -Wno-format-unknown-specifier would be accepted if
properly submitted:

http://gcc.gnu.org/contribute.html

See how the other Wformat-* options are defined in gcc/c-family/c.opt. Then,
grep for unknown conversion type character, and just change OPT_Wformat in the
warning call. You'll have to add new testcases and adjust existing ones.

[Bug c/47781] warnings from custom printf format specifiers

[mark-gcc at glines dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781

--- Comment #2 from Mark Glines <mark-gcc at glines dot org> 2011-02-17 11:58:22 UTC ---
Created attachment 23380
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23380
47781.c

Here's a rather silly test case that demonstrates the problem with a simple
"bool" type.

$ gcc -O2 -Wall -o 47781 47781.c
47781.c: In function ‘main’:
47781.c:12: warning: unknown conversion type character ‘b’ in format
47781.c:12: warning: unknown conversion type character ‘b’ in format
47781.c:12: warning: too many arguments for format
$ ./47781
true bool: TRUE  false bool: FALSE
$


(That's on x86-64 linux with gcc 4.4.4-14ubuntu5 and libc6 2.12.1-0ubuntu10.2.)

[Bug c/47781] warnings from custom printf format specifiers

[mark-gcc at glines dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781

--- Comment #3 from Mark Glines <mark-gcc at glines dot org> 2011-02-17 12:00:40 UTC ---
(In reply to comment #1)
> I think a patch that adds -Wno-format-unknown-specifier would be accepted if
> properly submitted:

Okay, I'll take a look at putting together a patch.  Thanks!

[Bug c/47781] warnings from custom printf format specifiers

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781

--- Comment #4 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2011-02-17 18:24:25 UTC ---
On Thu, 17 Feb 2011, mark-gcc at glines dot org wrote:

> I'd like to request a finer grained means of control.  A syntactical element
> (builtin/pragma/attribute/whatever) to pre-declare a format conversion and the
> typedef to check it against would be very nice, if complex.  A much simpler
> solution would be a -Wno-format-unknown-specifier option, which skips the
> argument in the argument list and otherwise ignores conversions it doesn't
> recognize.

You can't reliably know how many arguments the unknown specifier takes, 
though assuming them to take one argument would be a reasonable heuristic 
for such an option.

For the general issue, my inclination is that we should add plugin hooks 
into the format checking machinery that allow plugins to define formats 
with the full flexibility of all the format checking datastructures in 
GCC.  Using GCC plugins for this avoids problems with defining complicated 
syntax in the source file to describe the peculiarities of different 
formats, which might constrain future changes to the format checking 
implementation by making too much of the internals visible to user source 
code, because by design GCC plugins can use GCC internals which are free 
to change incompatibly in ways that require plugin changes.

[Bug c/47781] warnings from custom printf format specifiers

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-09-23
     Ever confirmed|0                           |1

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed.

[Bug c/47781] warnings from custom printf format specifiers

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daniel.santos at pobox dot com

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 58512 has been marked as a duplicate of this bug. ***

[Bug c/47781] warnings from custom printf format specifiers

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Related to bug 15338.

[Bug c/47781] warnings from custom printf format specifiers

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781

--- Comment #9 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Thu, 21 Aug 2014, philipp_subx@redfish-solutions.com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781
> 
> --- Comment #8 from Philip Prindeville <philipp_subx@redfish-solutions.com> ---
> (In reply to joseph@codesourcery.com from comment #4)
> 
> > For the general issue, my inclination is that we should add plugin hooks 
> > into the format checking machinery that allow plugins to define formats 
> > with the full flexibility of all the format checking datastructures in 
> > GCC.  Using GCC plugins for this avoids problems with defining complicated 
> > syntax in the source file to describe the peculiarities of different 
> > formats, which might constrain future changes to the format checking 
> > implementation by making too much of the internals visible to user source 
> > code, because by design GCC plugins can use GCC internals which are free 
> > to change incompatibly in ways that require plugin changes.
> 
> What about using pragmas to describe the new format specifier?

Those have the issue of either being limited in the sorts of formats that 
can be described, or else exposing more internals than seems desirable to 
expose as a stable interface.  Plugins allow full flexibility (with 
possible instability of interfaces), though a stable subset (e.g. formats 
that take no length modifiers or flags) could probably be defined that has 
a stable interface in source files (such as through attributes or pragmas) 
that doesn't unduly constrain the internals of the implementation.  But I 
think any such stable interface would not be able to describe the full 
generality of the existing built-in formats.

One interesting question would be whether a good stable interface can be 
defined that is general enough to describe GCC's internal formats - 
whether those are regular enough that a description isn't tied to 
hardcoded special cases or extremely complicated descriptions of what 
cases should / should not get warnings.

[Bug c/47781] warnings from custom printf format specifiers

[philipp_subx@redfish-solutions.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781

--- Comment #10 from Philip Prindeville <philipp_subx@redfish-solutions.com> ---
On Aug 21, 2014, at 11:06 AM, joseph at codesourcery dot com
<gcc-bugzilla@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781
> 
> --- Comment #9 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
> On Thu, 21 Aug 2014, philipp_subx@redfish-solutions.com wrote:
> 
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781
>> 
>> --- Comment #8 from Philip Prindeville <philipp_subx@redfish-solutions.com> ---
>> (In reply to joseph@codesourcery.com from comment #4)
>> 
>>> For the general issue, my inclination is that we should add plugin hooks 
>>> into the format checking machinery that allow plugins to define formats 
>>> with the full flexibility of all the format checking datastructures in 
>>> GCC.  Using GCC plugins for this avoids problems with defining complicated 
>>> syntax in the source file to describe the peculiarities of different 
>>> formats, which might constrain future changes to the format checking 
>>> implementation by making too much of the internals visible to user source 
>>> code, because by design GCC plugins can use GCC internals which are free 
>>> to change incompatibly in ways that require plugin changes.
>> 
>> What about using pragmas to describe the new format specifier?
> 
> Those have the issue of either being limited in the sorts of formats that 
> can be described, or else exposing more internals than seems desirable to 
> expose as a stable interface.  Plugins allow full flexibility (with 
> possible instability of interfaces), though a stable subset (e.g. formats 
> that take no length modifiers or flags) could probably be defined that has 
> a stable interface in source files (such as through attributes or pragmas) 
> that doesn't unduly constrain the internals of the implementation.  But I 
> think any such stable interface would not be able to describe the full 
> generality of the existing built-in formats.
> 
> One interesting question would be whether a good stable interface can be 
> defined that is general enough to describe GCC's internal formats - 
> whether those are regular enough that a description isn't tied to 
> hardcoded special cases or extremely complicated descriptions of what 
> cases should / should not get warnings.
> 

Yeah, I agree: if the notation is adequate, all existing formats should be
expressible using it.

[Bug c/47781] warnings from custom printf format specifiers

[tromey at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781

Tom Tromey <tromey at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at gcc dot gnu.org

--- Comment #11 from Tom Tromey <tromey at gcc dot gnu.org> ---
(In reply to joseph@codesourcery.com from comment #4)

> For the general issue, my inclination is that we should add plugin hooks 
> into the format checking machinery that allow plugins to define formats 
> with the full flexibility of all the format checking datastructures in 
> GCC.

I agree this makes sense for the general case, but I wanted to point out
that requiring a plugin for the simple cases is significantly harder for
users than some in-source extension mechanism.

E.g., firefox has a logging printf that accepts "%hs" to print char16_t*
strings.  This extension means that printf checking can't be used here.
Requiring a plugin to deal with this situation would also be difficult.
However letting one write __attribute__((printf, 1, 2, "hs", char16_t*))
would solve this nicely.

I suppose I think that a format-for-a-specific-type is the most common
kind of extension and so may deserve special treatment.

[Bug c/47781] warnings from custom printf format specifiers

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781

--- Comment #12 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Thu, 29 Jan 2015, tromey at gcc dot gnu.org wrote:

> E.g., firefox has a logging printf that accepts "%hs" to print char16_t*
> strings.  This extension means that printf checking can't be used here.
> Requiring a plugin to deal with this situation would also be difficult.
> However letting one write __attribute__((printf, 1, 2, "hs", char16_t*))
> would solve this nicely.

Do you then take this as being length modifier 'h' followed by format 
specifier 's', or is it a complete specifier on its own with everything 
that would otherwise be length and specifier being reparsed as an 
extension if it can't be parsed as a standard format?  Do the flags "-wp" 
and "cR" for %s formats apply to this format?

[Bug c/47781] warnings from custom printf format specifiers

[tromey at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781

--- Comment #13 from Tom Tromey <tromey at gcc dot gnu.org> ---
(In reply to joseph@codesourcery.com from comment #12)
> On Thu, 29 Jan 2015, tromey at gcc dot gnu.org wrote:
> 
> > E.g., firefox has a logging printf that accepts "%hs" to print char16_t*
> > strings.  This extension means that printf checking can't be used here.
> > Requiring a plugin to deal with this situation would also be difficult.
> > However letting one write __attribute__((printf, 1, 2, "hs", char16_t*))
> > would solve this nicely.
> 
> Do you then take this as being length modifier 'h' followed by format 
> specifier 's', or is it a complete specifier on its own with everything 
> that would otherwise be length and specifier being reparsed as an 
> extension if it can't be parsed as a standard format?  Do the flags "-wp" 
> and "cR" for %s formats apply to this format?

I see what you mean -- maybe "simple" isn't straightforward.

I have been reconsidering the plugin approach given some new things
I learned about the details of the firefox code (namely that it doesn't
faithfully follow printf semantics, sigh).

One additional note for this bug is that it would be nice if any
such addition by a plugin worked properly with -Wmissing-format-attribute.

[Bug c/47781] warnings from custom printf format specifiers

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781

--- Comment #14 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Tom Tromey from comment #13)
> I have been reconsidering the plugin approach given some new things
> I learned about the details of the firefox code (namely that it doesn't
> faithfully follow printf semantics, sigh).
> 
> One additional note for this bug is that it would be nice if any
> such addition by a plugin worked properly with -Wmissing-format-attribute.

Note that plugins can define attributes. Perhaps one way to go about this would
be to create a plugin that parsed some kind of GCC_printf_format_info attribute
that matches GCC internal printf checking. Then move GCC own format checking to
use this attribute and enable the plugin by default when building GCC.

This will give you as much flexibility as GCC format checking supports, and the
plugin will be developed, build, tested and distributed alongside GCC. Users
outside GCC just need to use the plugin and add the attributes to their own
printf-style functions. Moreover, since the plugin is developed alongside GCC,
it would be logical to add whatever hooks the plugin needs.

Moreover, nothing stops users from creating some kind of intermediate language
that simplifies custom printf attribute syntax. Probably some C preprocessor
magic could be enough.

The challenge is the define the syntax of the attribute, but I think this
challenge is unavoidable for whoever wants to implement this. You may present a
simplified syntax to the user, but you still need to handle correctly all the
complexity and corner cases in c-format.c.
>From gcc-bugs-return-476017-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Feb 04 18:45:31 2015
Return-Path: <gcc-bugs-return-476017-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 9157 invoked by alias); 4 Feb 2015 18:45:30 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 9092 invoked by uid 48); 4 Feb 2015 18:45:27 -0000
From: "pault at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/64921] [4.9/5 Regression] FAIL: gfortran.dg/class_allocate_18.f90
Date: Wed, 04 Feb 2015 18:45:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: pault at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-64921-4-INab0mJH2T@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64921-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64921-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-02/txt/msg00350.txt.bz2
Content-length: 1491

https://gcc.gnu.org/bugzilla/show_bug.cgi?idd921

--- Comment #8 from Paul Thomas <pault at gcc dot gnu.org> ---
(In reply to H.J. Lu from comment #7)
> (In reply to Paul Thomas from comment #6)
> > (In reply to H.J. Lu from comment #2)
> > > I got
> > >
> > > Program received signal SIGSEGV: Segmentation fault - invalid memory
> > > reference.
> > >
> > > Backtrace for this error:
> > > #0  0xF763FACE
> > > #1  0xF763EBDE
> > > #2  0xF773CBBF
> > > #3  0x8048BA5 in __final_main_T2.3337 at class_allocate_18.f90:?
> > > #4  0x8048D68 in __final_main_T3.3328 at class_allocate_18.f90:?
> > > #5  0x8048A59 in MAIN__ at class_allocate_18.f90:?
> > > FAIL: gfortran.dg/class_allocate_18.f90   -O1  execution test
> > >
> > > But I couldn't reproduce it on another machine. I will keep an eye on it.
> >
> > Hi HJ,
> >
> > Given that the error is sporadic, are you sure that the offending revisions
> > are not 220125 and 220130 - PR64230. The error messages that you are getting
> > are remarkably similar to the original report for this PR.
> >
>
> I don't know for sure.  This failure seems more consistent on 4.9 branch
> than on trunk.

Dear HJ,

I can confirm that the part of resolve.c modified in r220191 is not visited by
the compilation of class_allocate_18.f90.

If I have understood correctly, -fPIC is not supported on x86_64 and so, unless
I am mistaken, I cannot help you further.

Please let me know if there is anything that I can do to help.

Best regards

Paul

[Bug c/47781] warnings from custom printf format specifiers

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781

Eric Gallager <egall at gwmail dot gwu.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |egall at gwmail dot gwu.edu

--- Comment #15 from Eric Gallager <egall at gwmail dot gwu.edu> ---
(In reply to Tom Tromey from comment #11)
> ...I wanted to point out that requiring a plugin for the simple cases is
> significantly harder for users than some in-source extension mechanism.
> 
> E.g., firefox has a logging printf that accepts "%hs" to print char16_t*
> strings.  This extension means that printf checking can't be used here.
> Requiring a plugin to deal with this situation would also be difficult.
> However letting one write __attribute__((printf, 1, 2, "hs", char16_t*))
> would solve this nicely.
> 
> I suppose I think that a format-for-a-specific-type is the most common
> kind of extension and so may deserve special treatment.

Wow, this is pretty much the same syntax I imagined when coming across this
issue independently! Except in my idea, I changed the name of the format
attribute to "printf-extended", to make it more obvious what the extra
arguments are. The case where I came across it was in trying to build a forked
old version bfd with -Wsuggest-attribute=format and -Wformat=2, where I was
unable to attach a format attribute to the bfd_error_handler_type declaration.
This is because _bfd_default_error_handler is extended to accept 2 new format
specifiers: %A, which takes args of type asection*, and %B, which takes args of
type bfd*. Using an attribute as proposed above, it'd be simple to just write
something like,

__attribute__((format(printf-extended, 1, 2, "A", asection*, "B", bfd*)))

Although checking the commentary on newer mainline versions of the
_bfd_default_error_handler function, it looks like it does some additional
weird stuff with the argument order, but still, support for extending the
format attribute like this would still be a good start!

[Bug c/47781] warnings from custom printf format specifiers

[dcrocker at eschertech dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781

David Crocker <dcrocker at eschertech dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dcrocker at eschertech dot com

--- Comment #23 from David Crocker <dcrocker at eschertech dot com> ---
I need this feature too. Instead of waiting several more years for an
all-singing all-dancing solution, PLEASE can we have a simple solution that
allows me to use a custom format specifier and skips a single argument for that
specifier. I believe this would cover the vast majority of uses custom format
specifiers. My particular use case is that my application generates a lot of
JSON strings, so in my printf replacement I want to implement a specifier
similar to %s that performs JSON escaping on characters in the string.

[Bug c/47781] warnings from custom printf format specifiers

[tromey at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781

--- Comment #24 from Tom Tromey <tromey at gcc dot gnu.org> ---
(In reply to David Crocker from comment #23)
> I need this feature too. Instead of waiting several more years for an
> all-singing all-dancing solution, PLEASE can we have a simple solution that
> allows me to use a custom format specifier and skips a single argument for
> that specifier. I believe this would cover the vast majority of uses custom
> format specifiers. My particular use case is that my application generates a
> lot of JSON strings, so in my printf replacement I want to implement a
> specifier similar to %s that performs JSON escaping on characters in the
> string.

As a workaround, see the kernel doc linked earlier in this bug.
gdb uses this hack as well -- e.g., it uses "%ps" in its formatter
to mean a styled string, passed as a pointer to get past gcc's checking.

[Bug c/47781] warnings from custom printf format specifiers

[grant.b.edwards at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781

Grant Edwards <grant.b.edwards at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |grant.b.edwards at gmail dot com

--- Comment #25 from Grant Edwards <grant.b.edwards at gmail dot com> ---
10 years later, still no solution? I too would really like to be able to
use custom single-argument, single-character format specifies (e.g. %b to
print an integer in binary).

The Linux-kernel work-around with %p<whatever> is painful for two reasons:

 * My printf function doesn't support format modifiers like that. All
   format specifiers are single characters.

 * You have to cast the integer value to a void*, and that just confuses
   the reader.

[Bug c/47781] warnings from custom printf format specifiers

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781

--- Comment #26 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
It's hard to define something that is sufficiently general to be useful 
but doesn't expose too much of the details of GCC's internal data 
structures for describing standard formats.  %b for binary is now a 
standard C23 format and supported for GCC 12 and later.

[Bug c/47781] warnings from custom printf format specifiers

[jan@swi-prolog.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781

Jan Wielemaker <jan@swi-prolog.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jan@swi-prolog.org

--- Comment #27 from Jan Wielemaker <jan@swi-prolog.org> ---
It is really a pity this can't be resolved :(  We have quite a few extensions
in the SWI-Prolog source code, mostly for debug messages that deal with
internal data structures.   It makes writing debug messages a lot easier.

What about this:  add a pragma that associates a regular expression with a list
of types.  For example (don't take this literally, I know little about the
#pragma conventions).

#pragma GCC printf "t" (term_t)

Now if the compiler scans a template and finds a %, it runs through these
declarations in the order they have been declared.  On the first match it knows
the type(s) expected from the argument list and continues after the regex
match.

[Bug c/47781] warnings from custom printf format specifiers

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781

--- Comment #28 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Jan Wielemaker from comment #27)
> It is really a pity this can't be resolved :(  We have quite a few
> extensions in the SWI-Prolog source code, mostly for debug messages that
> deal with internal data structures.   It makes writing debug messages a lot
> easier.

This can be resolved. It only needs someone(s) interested enough to implement
it or pay someone else to implement it. 

There are a lot of suggestions in this page on how to proceed. Personally, I
think the best would be to start with a simple design for an attribute rather
than a pragma and implement it as a plugin to faster development and testing.
Then submit it for comments. The simplest design that will get you faster
feedback would be something the replaces some of the current GCC-specific
printf formats, like %E, %T, %q, etc. 

(I don't remember where these are documented and implemented right now)

It just needs people with time and patience to do it.

[Bug c/47781] warnings from custom printf format specifiers

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781

--- Comment #29 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
As I said before, the issue is still how to define something general 
enough to be useful but that doesn't expose too much of the details of 
GCC's internal data structures for format checking.

[Bug c/47781] warnings from custom printf format specifiers

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781

--- Comment #30 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to joseph@codesourcery.com from comment #29)
> As I said before, the issue is still how to define something general 
> enough to be useful but that doesn't expose too much of the details of 
> GCC's internal data structures for format checking.

Indeed, the first step does not even require looking at GCC code or an
implementation, but coming up with a design that is flexible enough to be
useful.