2004-01-24 15:12:02

by Dave Gilbert (Home)

[permalink] [raw]
Subject: RFC: Representation of large hex values

(OK, this isn't strictly a kernel thing - but it seems to be a good
place for peoples thoughts on this, and the kernel would be one
place to start it off)

The problem: Large (64 bit) hex values are cumbersome - especially
when they contain strings of 0's in the middle

Suggestion: Print hex value with a seperator every 4 or 8 nybbles
to aid in counting. After some discussion it seems that _
is a decent seperator - e.g.

1000_0000_0000_1234

this is especially useful when you have a pile of numbers like

1000000021771245

and you are trying to see if that is bigger or smaller than
the number 1000000232349876, yet it is pretty obvious when you
try and compare 1000_0000_2177_1245 and 1000_0002_3234_9876.

I originally thought of using : like IPv6 but this can get
in the way on languages which use : for other things.
(and I don't think it is worth doing packed numbers like IPv6
does - i.e. 1000_0_2177_1245 would be invalid).

For clarity, it would seem best to use a distinct format character;
so perhaps prefix these numbers by 0y (read Oi!) and then you
could use %y (and %Y if you REALLY want) in printf. Scanf equivalents
would be taught to understand both formats; using 0y and _ makes
code that doesn't understand the format fail noisily. So:

0ydead_beef_1ced_ac1d

I don't think there is the necessity to force zero padding, so
1_2177_1245 is valid; but _ shall not be the first character
(so as not to construct an identifier). (I'm vaguely remembering
that VHDL allows _ padding?)

If people like this then I'd be happy to write a modified
printf/scanf, and I suggest that it gets used in limited places
until the same could be integrated in gdb/binutils/other tools.

Suggestions and constructive comments welcome and apologies
for disturbing your games of wack-the-penguin.

Dave
P.S. Thanks go to members of the non-existant cabal on this.

-----Open up your eyes, open up your mind, open up your code -------
/ Dr. David Alan Gilbert | Running GNU/Linux on Alpha,68K| Happy \
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/


2004-01-24 15:42:18

by Philippe Elie

[permalink] [raw]
Subject: Re: RFC: Representation of large hex values

Dr. David Alan Gilbert wrote:
> (OK, this isn't strictly a kernel thing - but it seems to be a good
> place for peoples thoughts on this, and the kernel would be one
> place to start it off)
>
> The problem: Large (64 bit) hex values are cumbersome - especially
> when they contain strings of 0's in the middle
>
> Suggestion: Print hex value with a seperator every 4 or 8 nybbles
> to aid in counting. After some discussion it seems that _
> is a decent seperator - e.g.
>
> 1000_0000_0000_1234

You'll break people piping output to tools, you must
solve this by running the output to your own filter
which split hexa number.

regards,
Phil

2004-01-24 15:55:25

by Joe Korty

[permalink] [raw]
Subject: Re: RFC: Representation of large hex values

On Sat, Jan 24, 2004 at 03:30:12PM +0000, Dr. David Alan Gilbert wrote:
> (OK, this isn't strictly a kernel thing - but it seems to be a good
> place for peoples thoughts on this, and the kernel would be one
> place to start it off)
>
> The problem: Large (64 bit) hex values are cumbersome - especially
> when they contain strings of 0's in the middle
>
> Suggestion: Print hex value with a seperator every 4 or 8 nybbles
> to aid in counting. After some discussion it seems that _
> is a decent seperator - e.g.
>
> 1000_0000_0000_1234
>
> this is especially useful when you have a pile of numbers like
>
> 1000000021771245
>
> and you are trying to see if that is bigger or smaller than
> the number 1000000232349876, yet it is pretty obvious when you
> try and compare 1000_0000_2177_1245 and 1000_0002_3234_9876.
>
> I originally thought of using : like IPv6 but this can get
> in the way on languages which use : for other things.
> (and I don't think it is worth doing packed numbers like IPv6
> does - i.e. 1000_0_2177_1245 would be invalid).
>
> For clarity, it would seem best to use a distinct format character;
> so perhaps prefix these numbers by 0y (read Oi!) and then you
> could use %y (and %Y if you REALLY want) in printf. Scanf equivalents
> would be taught to understand both formats; using 0y and _ makes
> code that doesn't understand the format fail noisily. So:
>
> 0ydead_beef_1ced_ac1d
>
> I don't think there is the necessity to force zero padding, so
> 1_2177_1245 is valid; but _ shall not be the first character
> (so as not to construct an identifier). (I'm vaguely remembering
> that VHDL allows _ padding?)
>
> If people like this then I'd be happy to write a modified
> printf/scanf, and I suggest that it gets used in limited places
> until the same could be integrated in gdb/binutils/other tools.
>
> Suggestions and constructive comments welcome and apologies
> for disturbing your games of wack-the-penguin.

Hi David,
2.6.1-mm4 has a variant of this, limited to bitmaps and using the
comma as the seperator. See bitmap_parse and bitmap_snprintf in
lib/bitmap.c

Replacing the comma with the underscore and moving the whole shebang
to printf/scanf sounds like a good idea to me. Printf *should* be
able to manipulate bitmaps just as it does for other basics types
like strings and ints.

Why don't you whip up a patch and see what happens?

Regards,
Joe

2004-01-24 16:24:40

by Andreas Schwab

[permalink] [raw]
Subject: Re: RFC: Representation of large hex values

"Dr. David Alan Gilbert" <[email protected]> writes:

> For clarity, it would seem best to use a distinct format character;
> so perhaps prefix these numbers by 0y (read Oi!) and then you
> could use %y (and %Y if you REALLY want) in printf.

POSIX defines the ' flag to enable use of thousand separators for decimal
formats. This could easily be extended to hex formats.

Andreas.

--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux AG, Maxfeldstra?e 5, 90409 N?rnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."