On Sat, 19 Aug 2006, [EMAIL PROTECTED] wrote:
For example in ip4unix.c the following line is within ip_nametoaddr()
if (len) *len = he->h_length;
but len is defined as size_t in the calling function. On 64-bit size_t
is 64-bit but he->h_length is 32-bit. Depending on your byte order
this can result in len being set to 0.
You have to be kidding me!
len is prototyped in the function as size_t*. Similarly, he->h_length is
also prototyped. So, the compiler knows the sizes of both values, and
thus should know how to do a loss-free copy.
In the scenario that you outlined, a 32-bit value is being assigned to a
64-bit object. K&R stipulates that "the right operand [the 32-bit value]
is converted to the type of the left [the 64-bit object] by the
assignment." How can anyone justify this conversion being implemented as
"set to 0"?
Now, if the reverse was done, I could see the compiler complaining. But
if it truncated the MSBs the right thing would happen since the value is
never going to be anywhere near a high enough magnitude for it to matter.
Unless an application has been specifically written with 64-bit in mind
it is unlikely to work out of the box and even if you do get it compile
and run then without detailed code analysis something will bite you
one day.
Sigh. The whole point of prototyping in C is so that this isn't a
problem. Knowing the sizes, the compiler should zero-pad when a
smaller-type value is assigned to a larger type, and should issue a
diagnostic if the reverse happens without an explicit cast.
IMHO, the designers of 64-bit C blew it.
In summary, stick with 32-bit as Mark says!
Sad, but true.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
_______________________________________________
Imap-uw mailing list
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
