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 [EMAIL PROTECTED]
