On Thu, 01 May 2008 17:31:38 -0400, mimus
hotmail.com>
wrote:
>On Wed, 30 Apr 2008 18:53:48 -0700, Barry Schwarz wrote:
>
snip
>>>printf ( "%%lu\n", *d3p )
>>>
>>>should print out 2.2.
>>>
>>>(And autoincrement your way up a stack-o'-doubles if you want, using *d3p++.)
>>
>> You cannot assumes the doubles are arranged nicely in memory.
>
>I can if I put them there.
The is no way in C to specify the placement of independent objects.
Given
double d1, d2;
you do not know id d1 is before or after d2 nor do you know if they
abut.
>
>Heh.
>
>Also, pointers increment according to pointed data-type, hence K&R 2d
>ed.'s "an array-and-index expression is equivalent to one written as a
>pointer and offset", and "a[i] can also be written as *(a + i)".
True for arrays, not for independent objects.
>
>Eg, a float pointer pointing to a float in a calloc()ed pseudo-array of
>floats, when incremented, will point to the next float.
True but it has nothing to do with defined variables.
>
>More scarily, perhaps, a struct pointer pointing to a struct in a
>calloc()ed array of structs, etc. (This would seem to call for some extra
>compiler finagling in the case of the newfangled 1999 structs that can
>have variable-length final elements.)
The standard prohibits such a struct from being an element of an
array.
>
>I used cast char pointers incremented by the data-type size from sizeof to
>move up and down, eg, unsigned long stacks for years until I finally
>caught on that the appropriate pointer would do that for me automagically
>on incrementation or decrementation.
The fact that this particular type of undefined behavior appeared to
work on your system does not make it any less undefined.
Remove del for email
