> Once K&R is included, the situation becomes a lot less clear. Also, as I
> read the thread on the GCC list, it looks like the situation is further
> complicated by their desire to avoid an internal compiler error.
> Also**2,
> I don't know what you mean by C's aliasing rules; to me that brings to
> mind the ill-conceived 'noalias' qualifier.
>
> If this is worth further discussion, a concrete example (code fragment)
> would help me a lot.
>
> /r$
What I mean by aliasing rules is that with only a few exceptions, a compiler
is allowed to assume that an access through a pointer of one type cannot
affect the value of a variable of a different type.
GCC's optimization in this area has gotten to the point where it bites a lot
of people, and I think it's the aliasing issue that's the problem for
OpenSSL, not really the function prototype issue. Right now, the GCC bug
with the most duplicates is due to aliasing errors.
The GCC "not a bug" page gives this example:
int main()
{
short a[2];
a[0]=0x1111;
a[1]=0x1111;
*(int *)a = 0x22222222; /* violation of aliasing rules */
printf("%x %x\n", a[0], a[1]);
return 0;
}
The compiler has every right to print 1111 and 1111, because under C rules,
no modification to an integer can change the value of a short.
However, this is also an example:
extern void foo();
int main(void)
{
int j=2;
foo((double *) &j);
printf("%d\n", j);
return 0;
}
The compiler has every right to assume that 'j' still has the value '2' in
the 'printf' call because 'j' is local to 'main' and no modification through
a 'double *' pointer can possibly change the value of an 'int'.
GCC 403 warns about this (with flags: -O3 -Wall)
test.c:9: warning: dereferencing type-punned pointer will break
strict-aliasing rules
Line 9 is the call to 'foo'.
OpenSSL's PEM #define's do the same thing as this example.
However, if OpenSSL fixes its aliasing issues and *still* has a problem,
then I think you can complain to the GCC guys. I think the current GCC issue
can be tripped even in code which doesn't violate aliasing rules, but I
think you still have to violate the parameter passing rules.
So either way, it's not GCC's fault strictly speaking. Though GCC's behavior
is suboptimal, certainly. GCC will take care of its problems, but OpenSSL
should take care of its problems too. A lot of older code is getting bitten
by compilers that more heavily optimize and break code that uses illegal
type-punning.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
