David Schwartz wrote:

>>An object may be the type of its last cast -- but it also can't
>>exactly lose the benefit/cost of being cast to a pointer to an
>>undefined type. As soon as you undefine the type of a pointer, it
>>loses the remnant of ever having had the initial type in the first
>>place.
>>
>>

>
>Right, but that doesn't help you. For example:
>
>int j=2;
>double *d=(double *)(void *)&j;
>*d=1.0;
>printf("%d\n", j);
>
>This can output 2. Even though '&j' lost all intness by the cast to 'void *', it got 100% doubleness by the cast to 'double *'. The compiler can still assume that '*d' will not affect the value of 'j' because 'd' is a pointer to a type that is incompatible with 'j's type.
>
>The rule still stands -- a modification through a pointer to one type can be assumed not to change the value of a variable of an incompatible type.
>
>This is still what OpenSSL does when it passes an 'X509 **' as a 'char **'.
>
>

Are you sure that problem is in cast ?

$ cat test.c
main() {
int j=2;
double *d=(double*)&j;
*d=1.0;
printf("%d %e\n", j, *d);
printf("%d %e\n", j, *d);
}
gcc -O2 test.c && ./a.out
2 1.000000e+00
0 1.000000e+00

Same result in case with line "double *d=&j;" (but expected warning:
initialization from incompatible pointer type) and "double
*d=(double*)(void*)&j;"


Thanks to point side effect of -O2 in gcc.

May be is related to -fstrict-aliasing.
The above code we can found in gcc documentation for -fstrict-aliasing.

More results:
$ gcc -O2 -fno-strict-aliasing test.c && ./a.out
0 1.000000e+00
0 1.000000e+00
$ gcc -O1 -fstrict-aliasing test.c && ./a.out
0 1.000000e+00
0 1.000000e+00

> [SNIP]
>
>

It seem to me that all examples by David show noting related to the casts.
They only show problem by gcc -O2 .


Roumen

__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org