Maybe I should avoid making suggestions that would make the project
more complex, especially since I'm not implementing it, but...
If we can describe the argument types expected for a given format
string, then we can produce warnings for values used but not yet set
(%s with an uninitialized
[Sorry for the way-late response... was on vacation]
On Fri, Aug 19, 2005 at 02:16:53PM -0700, Ian Lance Taylor wrote:
> > The idea of letting gcc load a .so to do the checking also seems fine.
> > At least then the checking language is a standard one, not one we made
> > up.
I think this is a wo
Tom Tromey <[EMAIL PROTECTED]> writes:
> Ian> The second approach is of course to write a little language which is
> Ian> powerful enough to describe printf. The state machine language I
> Ian> described earlier is too simple and perhaps overly cryptic.
>
> If we're doing that, why not use an al
> "Ian" == Ian Lance Taylor writes:
Ian> To make this kind of thing useful, I see two paths that we can follow.
Ian> The second approach is of course to write a little language which is
Ian> powerful enough to describe printf. The state machine language I
Ian> described earlier is too simpl
On 2005-08-18 17:53:24 -0700, Joe Buck wrote:
> On Thu, Aug 18, 2005 at 11:52:36PM +0200, Vincent Lefevre wrote:
> > On 2005-08-18 21:53:47 +0200, Branko Čibej wrote:
> > > Mike Stump wrote:
> > [...]
> > > > printf ("%d", i);
> > [...]
> > > Now imagine that the output of the original program de
Alan Modra <[EMAIL PROTECTED]> writes:
> It's a great pity that vfprintf doesn't return its va_list arg. If it
> did, you could chop the format string into pieces and have vprintf
> process the normal parts, consuming args as it goes.
You can do relatively limited parsing and still identify how
James E Wilson wrote:
Joe Buck wrote:
The digits we use come from the Arabs, and look much the same in Arabic.
Check an Arabic-language site, for example http://www.aljazeera.net/ .
In English, we call them "Arabic Numerals", but that is a bit of a
misnomer. Once upon a time, a long time ago
Joe Buck wrote:
> The digits we use come from the Arabs, and look much the same in Arabic.
> Check an Arabic-language site, for example http://www.aljazeera.net/ .
In English, we call them "Arabic Numerals", but that is a bit of a
misnomer. Once upon a time, a long time ago, some Arabs used digit
On Thu, Aug 18, 2005 at 10:35:22AM -0400, Kaveh R. Ghazi wrote:
> > > 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
On Thu, Aug 18, 2005 at 11:52:36PM +0200, Vincent Lefevre wrote:
> On 2005-08-18 21:53:47 +0200, Branko Čibej wrote:
> > Mike Stump wrote:
> [...]
> > > printf ("%d", i);
> [...]
> > Now imagine that the output of the original program depends on the
> > locale that's in force at execution time, w
On Aug 18, 2005, at 12:53 PM, Branko Čibej wrote:
Now imagine that the output of the original program depends on the
locale that's in force at execution time
Now imagine that you can't use locale specific functions for these
things.
On 2005-08-18 21:53:47 +0200, Branko Čibej wrote:
> Mike Stump wrote:
[...]
> > printf ("%d", i);
[...]
> Now imagine that the output of the original program depends on the
> locale that's in force at execution time, which defines numberic
> output to be in arabic numerals (real ones, not the sor
Mike Stump wrote:
Imagine the following program:
{
int i = 234234;
printf ("%d", i);
}
imagine the folder collapsing this to puts ("234234");
Now imagine that the output of the original program depends on the
locale that's in force at execution time, which defines numberic output
to
On Aug 18, 2005, at 5:08 AM, Dave Korn wrote:
I was referring to this bit:
Remember that it's not enough simply to execute the optimizers.
You have to build a symbol table and an environment for the code
to execute in.
IIUIC, that would be a requirement for the optimisers to be able to
Florian Weimer <[EMAIL PROTECTED]> writes:
> > Do we have a sane way to (partially) execute optimizers at -O0
> > without screwing up with the pass manager too much?
>
> Do we have to provide user-defined format string warnings at -O0?
Yes, we do.
(But, although I don't like this approach, I th
> > 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
On Thu, Aug 18, 2005 at 08:46:04AM -0400, Kaveh R. Ghazi wrote:
> 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 t
> > Yeah, BFD can only do that because it forces the %A %B specifiers be
> > in the front.
>
> No, it's worse than that. %A and %B can appear anywhere in the format
> string, but consume their args first. eg.
>
> _bfd_default_error_handler ("section %d is called %A", sec, 1);
>
> Alan
Original Message
>From: Florian Weimer
>Sent: 18 August 2005 13:00
> * Dave Korn:
>
>> PMFBI, but how is all this going to work on a cross compiler?
>
> Constant folding works in a cross-compiler, too. 8-)
I was referring to this bit:
> Remember that it's not
> enough simply to e
* Dave Korn:
> PMFBI, but how is all this going to work on a cross compiler?
Constant folding works in a cross-compiler, too. 8-)
* Giovanni Bajo:
> Do we have a sane way to (partially) execute optimizers at -O0
> without screwing up with the pass manager too much?
Do we have to provide user-defined format string warnings at -O0?
Original Message
>From: Ian Lance Taylor
>Sent: 18 August 2005 02:20
> "Giovanni Bajo" writes:
>
>> Florian Weimer wrote:
>>
>>> Can't we just use some inline function written in plain C to check the
>>> arguments and execute it at compile time using constant folding etc.?
>>
>>
>> Do
On Wed, Aug 17, 2005 at 11:07:42PM -0400, Kaveh R. Ghazi wrote:
> Yeah, BFD can only do that because it forces the %A %B specifiers be
> in the front.
No, it's worse than that. %A and %B can appear anywhere in the format
string, but consume their args first. eg.
_bfd_default_error_handler ("sec
> But in cases like BFD, the code just does some pre-processing and then
> calls vfprintf. So there is no always correct value to inherit. The
> correct value to inherit from is the one which the user will link
> against, and for that the closest we can come to the right answer is
> the --st
"Kaveh R. Ghazi" <[EMAIL PROTECTED]> writes:
> I strongly feel that the "inherit" command should not change the
> behavior of the inherited format depending on the --std= flag passed
> to GCC at compile time of the user's code. This change isn't right
> for users, their variable argument output r
> For example,
>
> #pragma GCC format "bfd" "inherit printf; %A: asection; %B: bfd"
>
> Here the "inherit" could be simply "printf" for whatever is
> appropriate for the current compilation, or it could be a specific
> standard name.
I strongly feel that the "inherit" command should not c
> To make this kind of thing useful, I see two paths that we can follow.
> The first is to simply not try to implement all of printf in a special
> language. Most printf extensions are not nearly as complex as printf
> itself. In fact, most simply add a few additional % conversions, with
>
"Giovanni Bajo" <[EMAIL PROTECTED]> writes:
> Florian Weimer <[EMAIL PROTECTED]> wrote:
>
> > Can't we just use some inline function written in plain C to check the
> > arguments and execute it at compile time using constant folding etc.?
>
>
> Do we have a sane way to (partially) execute optim
Florian Weimer <[EMAIL PROTECTED]> wrote:
>> I haven't tried to flesh this out any further. I'd be curious to
>> hear how people react to it.
>
> Can't we just use some inline function written in plain C to check the
> arguments and execute it at compile time using constant folding etc.?
Do we
* Ian Lance Taylor:
> Florian Weimer <[EMAIL PROTECTED]> writes:
>
>> If I understand your %A/%B example correctly, it would look like this:
>
> OK, I can see how that might work in a simple case. Now, can you give
> me an example of matching %d with the various flags? In particular,
> are you g
Florian Weimer <[EMAIL PROTECTED]> writes:
> If I understand your %A/%B example correctly, it would look like this:
OK, I can see how that might work in a simple case. Now, can you give
me an example of matching %d with the various flags? In particular,
are you going to write a loop, and is gcc
* Ian Lance Taylor:
> Florian Weimer <[EMAIL PROTECTED]> writes:
>
>> * Ian Lance Taylor:
>>
>> > I haven't tried to flesh this out any further. I'd be curious to hear
>> > how people react to it.
>>
>> Can't we just use some inline function written in plain C to check the
>> arguments and exec
Florian Weimer <[EMAIL PROTECTED]> writes:
> * Ian Lance Taylor:
>
> > I haven't tried to flesh this out any further. I'd be curious to hear
> > how people react to it.
>
> Can't we just use some inline function written in plain C to check the
> arguments and execute it at compile time using co
On Aug 17, 2005, at 12:19 PM, Florian Weimer wrote:
Can't we just use some inline function written in plain C to check the
arguments and execute it at compile time using constant folding etc.?
I like this idea, but, I'm probably weird.
* Ian Lance Taylor:
> I haven't tried to flesh this out any further. I'd be curious to hear
> how people react to it.
Can't we just use some inline function written in plain C to check the
arguments and execute it at compile time using constant folding etc.?
"Kaveh R. Ghazi" <[EMAIL PROTECTED]> writes:
[ Moved from gcc-patches to gcc ]
> At this point, I don't do any parsing of the "format-checking-data",
> this is where I would expect Ian's state machine language to appear.
To make this kind of thing useful, I see two paths that we can follow.
Th
36 matches
Mail list logo
