This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap 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]

[Bug translator/14431] NULL/invalid char * pretty printed as "<unknown>" string


http://sourceware.org/bugzilla/show_bug.cgi?id=14431

Josh Stone <jistone at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jistone at redhat dot com

--- Comment #2 from Josh Stone <jistone at redhat dot com> 2012-08-05 20:29:44 UTC ---
(In reply to comment #1)
> What about we always also add the address of a char array?
[...]
> For our contrived example above that would give:
> 
> {.foo=""@0xcb4010, .foo_size=42, .bar=""@0xcb4050, .bar_size=47}
> {.foo="<unknown>"@0x0, .foo_size=42, .bar="<unknown>"@0x2a, .bar_size=0}
> 
> Does that look reasonable or silly?

It's tough to automagically do The Right Thing without knowing what the user is
looking for.  And in some cases, especially with kernel pointers, the %p may
overshadow the actual string, something like:

> {.foo=""@0xffffffffffcb4010, .foo_size=42, .bar=""@0xffffffffffcb4050, .bar_size=47}

Rather than trying both string value and address every time, maybe we should
make new kernel/user_string variants that return either a quoted string *or* a
pointer value, e.g. "\"foo\"" or "0x2a" depending on whether it's readable. 
Maybe "?@0x2a" to indicate it was tried but couldn't be read.  Your examples
would be:

> {.foo="", .foo_size=42, .bar="", .bar_size=47}
> {.foo=?@0x0, .foo_size=42, .bar=?@0x2a, .bar_size=0}

We can only try to be just so smart... for people who know they want something
different, like all pointer addresses, they can always roll their own
pretty-print.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


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