public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Kaveh R. Ghazi" <ghazi@caipclassic.rutgers.edu>
To: amodra@bigpond.net.au
Cc: gcc@gcc.gnu.org, ian@airs.com
Subject: Re: [PATCH]: Proof-of-concept for dynamic format checking
Date: Thu, 18 Aug 2005 14:35:00 -0000	[thread overview]
Message-ID: <200508181435.j7IEZMEr003144@caipclassic.rutgers.edu> (raw)
In-Reply-To: <20050818134117.GA2717@bubble.grove.modra.org>

 > > I don't know how wedded to this style the bfd folks are
 > 
 > Not at all.  In fact I don't like it, even though I wrote the code.
 > It would be great if _bfd_default_error_handler used the natural arg
 > positions for %A and %B.  I couldn't think of a way to do that without
 > incorporating a whole lot of knowledge about printf into the bfd
 > function.

Right, in GCC we ended up doing that except we only implemented the
bits of printf commonly used.  So for example we don't implement all
of the specifiers (floating point) or modifers (%h) or flags.  In fact
the fortran front end has a format that only has %d %i %c and %s from
printf, (plus two custom specifiers.)  No flags or even length
modifiers!

It's likely that bfd doesn't use a big chunk of printf that you could
leave out as well.  (I haven't actually audited bfd though).


Another option is to require positional specifiers for out of order
arguments.  E.g.

_bfd_default_error_handler ("section %2$d is called %1$A", sec, 1);

You could keep "sec" at the front, consume it, replace %1$A with the
appropriate string, and then pass the modified format string and the
partially consumed argument list to vfprintf.

Two problems, one is you'd have to modify (or delete) all the
positional parameters to account for taking out "sec".  So 2$ above
becomes 1$ or is eliminated.

Also, there's nothing to prevent someone from violating the rules
keeping "sec" in the front.


So I favor rewriting _bfd_default_error_handler to do the safer thing
which is to use natural arg positions.  Then create a format check
with only the stuff you need, not the whole printf style.

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

  reply	other threads:[~2005-08-18 14:35 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200508111509.j7BF9qMq015700@caipclassic.rutgers.edu>
2005-08-17 19:15 ` Ian Lance Taylor
2005-08-17 19:19   ` Florian Weimer
2005-08-17 19:25     ` Mike Stump
2005-08-17 19:25     ` Ian Lance Taylor
2005-08-17 19:45       ` Florian Weimer
2005-08-17 20:00         ` Ian Lance Taylor
2005-08-17 20:25           ` Florian Weimer
2005-08-18  1:00     ` Giovanni Bajo
2005-08-18  1:20       ` Ian Lance Taylor
2005-08-18 11:56         ` Dave Korn
2005-08-18 12:00           ` Florian Weimer
2005-08-18 12:09             ` Dave Korn
2005-08-18 19:10               ` Mike Stump
2005-08-18 19:54                 ` Branko Čibej
2005-08-18 21:52                   ` Vincent Lefevre
2005-08-19  0:54                     ` Joe Buck
2005-08-19  1:34                       ` James E Wilson
2005-08-19  2:23                         ` Robert Dewar
2005-08-19 10:32                       ` Vincent Lefevre
2005-08-18 22:51                   ` Mike Stump
2005-08-18 12:00       ` Florian Weimer
2005-08-18 16:38         ` Ian Lance Taylor
2005-08-19 19:40   ` Tom Tromey
2005-08-19 20:28     ` Internal Behavior of G++ Aoun Raza
2005-08-19 20:30       ` Joe Buck
2005-08-19 20:57         ` Aoun Raza
2005-08-19 21:11           ` Mike Stump
2005-08-19 21:17     ` [PATCH]: Proof-of-concept for dynamic format checking Ian Lance Taylor
2005-08-28 21:17       ` Daniel Jacobowitz
2005-08-28 23:28         ` Ken Raeburn
2005-08-18  2:01 ` Kaveh R. Ghazi
2005-08-18  2:08   ` Kaveh R. Ghazi
2005-08-18  2:50     ` Ian Lance Taylor
2005-08-18  3:07       ` Kaveh R. Ghazi
2005-08-18  3:42         ` Alan Modra
2005-08-18 12:46           ` Kaveh R. Ghazi
2005-08-18 13:41             ` Alan Modra
2005-08-18 14:35               ` Kaveh R. Ghazi [this message]
2005-08-19  1:08                 ` Alan Modra
2005-08-19  2:56                   ` Ian Lance Taylor

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=200508181435.j7IEZMEr003144@caipclassic.rutgers.edu \
    --to=ghazi@caipclassic.rutgers.edu \
    --cc=amodra@bigpond.net.au \
    --cc=gcc@gcc.gnu.org \
    --cc=ian@airs.com \
    /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).