Re: How does C cope if architecture doesn't address bytes?
From: James Harris (no.email.please)
Date: Wed, 17 Nov 2004 21:33:08 -0000
"Christian Bau" <email@example.com> wrote in message
> Now lets say you want to allocate an array for 100 doubles; one double
> is a native word of eight bytes. You will have sizeof (double) = 8, 100
> * sizeof (double) = 800, and malloc (800) returns a pointer to an array
> of 100 native words.
This is making more sense to me now. I'm a bit confused by the use of 800
in the malloc call above. Would malloc (100 * sizeof(double)) be more
portable? To be portable should all calls to malloc except chars specify
Incidentally, K&Rv2 in 7.8.5 Storage Management says than malloc returns a
pointer which has the proper alignment for the object in question. I can't
see that it can know for sure what the space is to be used for so assume
that malloc always returns a block of memory with the coarsest alignment
required by the implementation.
> One thing that might catch you out is that a cast from double* to char*
> to intptr_t to double* will most likely result in garbage, because the
> casts to and from intptr_t most likely don't change the respresentation,
> but the cast from double* to char* will change the representation. Cast
> from double* to intptr_t to double* would be fine, and so would be a
> cast from double* to char* to intptr_t to char* to double*, but not
> casting from char* to intptr_t and from intptr_t to double*.
I presume you mean that a char pointer would be shifted left three bits (in
this example) and the lower three bits used for the char within the machine
word. What would happen if those bits were not 000 and it was cast to a
double*? I suppose, more to the point, would the same thing happen in any
implementation when a char* is cast to a double* - possibly setting the low
bits to zero?
-- TIA, James