This is the mail archive of the gdb-prs@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

gdb/297: Dumb down longest_local_hex_string_custom()



>Number:         297
>Category:       gdb
>Synopsis:       Dumb down longest_local_hex_string_custom()
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    unassigned
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Mon Jan 28 12:48:02 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     ac131313@cygnus.com
>Release:        unknown-1.0
>Organization:
>Environment:

>Description:
Hello,

The sprintf("%llx",...) drew my attention to something else about that file.  All the local_hex_string stuff.

Looking at the code I'm getting the feeling that it is going out of its way to worry about long/long-long l/ll when it shouldn't at all.

Traditionally, printf() includes l/ll qualifiers so that it knows the size of arguments.  For insance:

    printf("%d\n", (long long) 1);

can be something of a disaster.  In the case of this code, however, I think GDB knows its size (it is LONGEST right?) and hence that info is completly redundant.  Instead GDB should just allow things like:

    (gdb) printf "%x", (long long) 1

Provided GDB interprets those formats directly and doesn't try to slip them through to sprintf() all should be ok.

Does anyone more familar with the code think this is a reasonable interpretation?  I hacked on it a few years back but at the time never thought to look at the big picture so the mess is probably part mine :-(

enjoy,
Andrew
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]