Cast alignment warnings
julien at trigofacile.com
Tue Aug 2 20:28:56 UTC 2011
> We take the address of the storage for a char (on the
> stack) and then pass it into a function that wants a pointer to an
> integer. The cast doesn't actually *do* anything other than silence the
> (correct) resulting warning; it's still the same address. Inside sscanf,
> you have loss of information: it has no idea that the pointer was
> originally to a char and takes our word for it that it is pointing to an
> integer's worth of storage, and then writes an integer's worth of data
> into that location.
Many thanks for the rewording. It is very clear.
You have a rare talent to explain things in simple, clear words. Not
everybody is capable of that. -- Well, I just wanted to tell you that
fact, but I do not doubt you were already aware of that :)
>> It would therefore require a subtle use of ntohs/htons calls.
> Yeah. But it's a self-created problem due to taking the address of a char
> and then telling another function to write an integer in it. If one just
> writes to an integer and then stores the value of the integer in a char,
> the compiler will add all the necessary conversion automatically.
Oh, yes, using a (temporary) integer variable to store the char is much
better and easier to read & debug.
> Integers in C can be 16, 32, or 64 bits depending on the
How can we then print size_t values?
As we do not know if it is an unsigned int or an unsigned long int, how
are we supposed to use printf or other similar functions?
Is "%z" possible/portable?
And if I write:
size_t i = 1;
printf("%lu", (unsigned long int) i);
Wouldn't it trigger an issue when i is an unsigned int? "%lu" will read
too many bytes, won't it? And also cause an issue on big-endian
systems, won't it?
« En France, on n'a pas de pétrole, mais on a des idées ! Alors,
j'ai troqué ma deux-chevaux contre une deux-bœufs ! » (Raymond
More information about the inn-workers