> alternatively we could encode "%t" as "%.s". this is an apparently
> non-sensical construct (print zero characters of the string) that we could
> overload with this meaning.
I prefer that; doing a lot of xml_quote everywhere is hassle. gcc will
not complain about "%.s" ?
At the end of this it
On Friday, 5. October 2007, Dirk Mueller wrote:
> sure, I'm more wondering what to do with "%t". in valgrind ,this is an
> XML-escaped "%s", while for printf its a length modifier, which causes
> quite some warnings.
>
> do we aim for thread safety? otherwise a xml_quote() around the argument
> s
On Friday, 5. October 2007, Nicholas Nethercote wrote:
> It sounds like changing it from a ',' to an apostrophe will fix any problem
> there. Dirk, are you happy to make that change along with the others in
> the branch? The relevant code is in coregrind/m_debuglog.c.
sure, I'm more wondering
On Thu, 4 Oct 2007, Dirk Mueller wrote:
> My primary concern was to ensure that no format string mismatches occur that
> could cause strange misbehaviour or crashes on rare (possible not regression
> tested) scenarios.
I've been annoyed several times in my recent Massif2 work with incorrect
form
On Thu, 4 Oct 2007, Dirk Mueller wrote:
> On Wednesday, 3. October 2007, Julian Seward wrote:
>
>> Addr/Word/UWord args with %p formats, either by casting the arg to void*
>> or changing the format to 0x%lx.
>
> I'm currently unable to decide which route to take. We can represent Addr in
> two way
On Wednesday, 3. October 2007, Julian Seward wrote:
> Addr/Word/UWord args with %p formats, either by casting the arg to void*
> or changing the format to 0x%lx.
I'm currently unable to decide which route to take. We can represent Addr in
two ways:
VG_(printf)("%#lx", ..)
or
VG_(printf)(
On Thursday, 4. October 2007, Nicholas Nethercote wrote:
> Making things more ANSI would be good
My primary concern was to ensure that no format string mismatches occur that
could cause strange misbehaviour or crashes on rare (possible not regression
tested) scenarios.
> , but then the ',' pr
On Monday, 1. October 2007, Bart Van Assche wrote:
> you changed the
> format string %08p into %p. As a result, the printed pointers are no longer
> right-aligned.
True. It was my impression that %p does this by default, but it seems I was
wrong. I'll correct this mistake shortly, thanks for po
On 10/4/07, Oswald Buddenhagen <[EMAIL PROTECTED]> wrote:
>
> On Thu, Oct 04, 2007 at 09:31:28AM +1000, Nicholas Nethercote wrote:
> > Making things more ANSI would be good, but then the ',' prefix is also
> > extremely useful -- it inserts commas into printed numbers, eg. prints
> > "1,234,567" in
On Thu, Oct 04, 2007 at 09:31:28AM +1000, Nicholas Nethercote wrote:
> Making things more ANSI would be good, but then the ',' prefix is also
> extremely useful -- it inserts commas into printed numbers, eg. prints
> "1,234,567" instead of "1234567". Any ideas for how to get the best of both
>
On Wed, 3 Oct 2007, Bart Van Assche wrote:
> The trend with gcc is that new versions move closer to the ANSI standard.
> Since the comma is not a valid flag character in ANSI C, we can expect that
> a future gcc version will complain about it. Do you think it would be a good
> idea to modify the V
On 10/3/07, Julian Seward <[EMAIL PROTECTED]> wrote:
>
>
> > I agree with the concerns raised above. But regarding (3): how about the
> > warnings gcc emits on format strings like "%,d", which are supported by
> > Valgrind but which are not allowed by ANSI C ?
>
> I wondered about that too, but at
> I agree with the concerns raised above. But regarding (3): how about the
> warnings gcc emits on format strings like "%,d", which are supported by
> Valgrind but which are not allowed by ANSI C ?
I wondered about that too, but at least using gcc 4.1.2 I got no complaints
about "%,d". So it see
On 10/3/07, Julian Seward <[EMAIL PROTECTED]> wrote:
>
>
> > I'm wondering what is the right thing to do here. Having the format
> string
> > warnings is nice, but we should be consistent. Eg. when printing
> pointers,
> > should we use %p and cast to (void*) when necessary, instead of using
> >
> I'm wondering what is the right thing to do here. Having the format string
> warnings is nice, but we should be consistent. Eg. when printing pointers,
> should we use %p and cast to (void*) when necessary, instead of using
> 0x%lx?
In the long run fixing the format strings to keep gcc happy
On Mon, 1 Oct 2007, Bart Van Assche wrote:
> Do you really know what you are doing ? You are not just fixing warnings,
> you are changing code. In trunk/coregrind/m_stacktrace.c you changed the
> format string %08p into %p. As a result, the printed pointers are no longer
> right-aligned. Did you u
Hello Dirk,
Do you really know what you are doing ? You are not just fixing warnings,
you are changing code. In trunk/coregrind/m_stacktrace.c you changed the
format string %08p into %p. As a result, the printed pointers are no longer
right-aligned. Did you understand what I wrote in the mail I se
17 matches
Mail list logo
