public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "joseph at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/47781] warnings from custom printf format specifiers
Date: Thu, 21 Aug 2014 17:07:00 -0000	[thread overview]
Message-ID: <bug-47781-4-bnrn9wbt9V@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-47781-4@http.gcc.gnu.org/bugzilla/>

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.


  parent reply	other threads:[~2014-08-21 17:07 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-17 11:55 [Bug c/47781] New: " mark-gcc at glines dot org
2011-02-17 11:58 ` [Bug c/47781] " manu at gcc dot gnu.org
2011-02-17 12:00 ` mark-gcc at glines dot org
2011-02-17 12:14 ` mark-gcc at glines dot org
2011-02-17 18:38 ` joseph at codesourcery dot com
2013-09-23 21:54 ` pinskia at gcc dot gnu.org
2013-09-23 21:55 ` pinskia at gcc dot gnu.org
2013-09-23 21:57 ` pinskia at gcc dot gnu.org
2014-08-21 17:07 ` joseph at codesourcery dot com [this message]
2014-08-21 17:54 ` philipp_subx@redfish-solutions.com
2015-01-29 16:42 ` tromey at gcc dot gnu.org
2015-01-29 21:55 ` joseph at codesourcery dot com
2015-02-04 17:38 ` tromey at gcc dot gnu.org
2015-02-04 18:44 ` manu at gcc dot gnu.org
2015-09-21 19:16 ` egall at gwmail dot gwu.edu
2020-12-13 15:48 ` dcrocker at eschertech dot com
2020-12-14 14:10 ` tromey at gcc dot gnu.org
2021-12-06 17:47 ` grant.b.edwards at gmail dot com
2021-12-06 22:48 ` joseph at codesourcery dot com
2023-01-18 11:03 ` jan@swi-prolog.org
2023-01-18 12:11 ` manu at gcc dot gnu.org
2023-01-18 17:40 ` joseph at codesourcery dot com
2023-01-18 17:46 ` manu at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-47781-4-bnrn9wbt9V@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).