In article <ne************ ********@news.d aimlerchrysler. com>,
Zoran Cutura <zo**********@w eb.de> wrote:
Walter Roberson <ro******@ibd.n rc-cnrc.gc.ca> wrote: It is undefined behaviour to have a format element for which the
parameter is missing or not of the matching type.
What your system is probably doing is converting whatever happens
to be on the stack, which probably happens to be a pointer with
value 0xff342088. If the same pointer happened to be on the stack
Mind you, but why would printf() convert a pointer instead of a value
here? I strongly doubt, that any implementation (though I might be
wrong) is doing it as you explain.
Let me re-state with a minor wording variation for clarity:
"What your system is probably doing is converting whatever
happens to be on the top of the stack, which is a value which
is 0xff342088, which is probably a pointer."
There is some question about the endianness of the original poster's
machine, so the integer value that printed out with value 0xff342088
might have been stored internally as 0x34, 0xff, 0x88, 0x20
or 0x88, 0x20, 0x34, 0xff or 0x20, 0x88, 0xff, 0x34 or some other
byte order. This confuses the determination of the likely type
of the stray value that happened to be printed out.
The original value was unlikely to have been an IEEE float or
double, as the values implied by any of the possible orderings
are fairly far away from 0 -- on the order of 1e-52 for the largest
of them.
The value is unlikely to have been a string: 0xff and 0x88 are
unlikely as desired ISO-8859-1 characters, and the values look
unlikely for UTF-8 or for any of the UTF variations that call for
"shift codes".
The value is unlikely to have been a random int lying around
in memory -- -13361016 is just a bit too random for that.
Scrambled variations on the value look -unlikely- as virtual
memory pointers.
I have, though, seen stray values in the 0xff342088 range on the
stack, mostly as stack pointers. Well, not quite: on the architecture
I normally use, 0x7f342088 is a plausible virtual stack pointer,
which happens to be upper memory as the high address bit of
memory addresses happens to be reserved in this architecture. But
on an architecture that didn't have that reservation, 0xff342088
could be a plausible stack pointer.
The one last thing I can think of as plausible, is that the
0xff342088 could be a relative branch address to return from the
present function.
Perhaps some day the OP will mention the architecture involved
and supply a short program to reproduce the output, and someone
might get bored enough to analyze the flow to find out exactly
how that -particular- value ended up being the value sitting
on the stack at the time of the undefined behaviour.
--
Many food scientists have reported chocolate to be the single most
craved food. -- Northwestern University, 2001
