printf

R

Richard Heathfield

Ian Collins said:
Shane wrote:

Long ago by people who knew what they were doing.

We still need people who know what they're doing. Curiosity is a *good*
thing.
 
K

Kelsey Bjarnason

Ian Collins said:


We still need people who know what they're doing. Curiosity is a *good*
thing.

People who *don't* know what they're doing, but have sufficient curiosity
to learn, are likewise a good thing to have around.
 
D

David Thompson

assuming you can dump data in hex:
ITYM 'you' (the OP or whoever) can _read_ hex
void xprint_binary_data (void *pointer_to_bin_data, int len)

In general 'int' is not the best type for length-of-memory values.
However, I personally don't want to read the dump of any item whose
length doesn't fit in the smallest permitted 'int' range.
{
unsigned int *t = (unsigned int *)pointer_to_bin_data;

A pointer to arbitrary data is not necessarily aligned correctly for
(unsigned) int, or in general for any noncharacter type, and there are
systems where this will indeed fail (trap or just give wrong data).
int i, ui_len = (len / sizeof (unsigned int));
And there's even less reason to assume that all data to be dumped will
be an exact multiple of the size of int (or whatever). Even in cases
(platforms or particular buffers) where you can get away with uint or
whatever access, you need to check for and handle a residue -- or, if
'word' access works at all it almost certainly works for the rest of
the word after the 'valid' object, so just print one extra word,
perhaps with some indication how much of it is unwanted.
for (i = 0; i < ui_len; i++)
{
printf ("%8.8x ", t);


This assumes I32, which is common but not universal. It's
straightforward, but ugly, to fix it for the other common sizes.

It also assumes no padding bits in the representation of uint, which
is not strictly guaranteed but is in (current?) practice universal.

It's easier and safer to do bytes using unsigned char, and for a dump
routine the slight inefficiency will be swamped by the cost of I/O.
Only in pure-CPU operations like memcpy() and memcmp() is doing
wordwise operations SOMETIMES worth it -- and the ones in the standard
library like those two can be optimized by the implementor without
your having to write, debug, and maintain platform (and even compiler)
dependent code.
if (i % 8 == 0) printf ("\n");

This produces a confusing output pattern: word 0 on first line, 1-8 on
second, 9-16 on third, etc. You want == 7. Or ~i % 8 == 0.

When doing bytewise, I like to use a technique (some might say trick)
to handle either within-the-line punctuation or end-of-line at once.
For your format (8 chunks of 4 bytes each per line):

for( i = 0; i < len; i++ ){
printf ("%02x", buf); /* assumes C8; check to be safe,
or use (bleah!) "%0*x", (int)(CHAR_BIT+3)/4, buf */
if( ++i == len ) putchar ('\n');
else if( i & 3 ) /* no separator */ ;
else putchar (i&0x1F? ' ' : '\n' );
}
}
printf ("\n");
}
- formerly david.thompson1 || achar(64) || worldnet.att.net
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,734
Messages
2,569,441
Members
44,832
Latest member
GlennSmall

Latest Threads

Top