Cast alignment warnings

[Julien ÉLIE]

Hi Russ,

> 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
> architecture

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?

-- 
Julien ÉLIE

« 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
   Devos)