Re: findings on swig-java-bindings

> If it's not a false alarm then it's not a gcc3 problem either and
> adding -fno-strict-aliasing would be simply hiding the problem. gcc
> is warning us that *any* C99 compiler is allowed to make these
> optimisations. Yes, adding -fno-strict-aliasing will stop gcc making
> the optimisations, but it provides no guarantee that some other
> compiler won't make the same assumptions and so optimise it.
>

I don't recall which one of the c standards it is, but it says that
variables of different types can't overlap, and therefore any
compiler can do "dangerous optimizations" on the generated code if
they feel like it.

So you are correct, the code is dangerous, and as such it should
preferably be fixed somehow.

The fixing however is, as stated previously, somwhat tricky, as the
problem actually lies withing swig.

It would however be possible to change the default swig-behaviour,
by adding declarations like the following to the (pre-swig)-code:

%typemap(in) SWIGTYPE * %{
{
        char* temp = (char *)&$input;
        $1 = *($&1_ltype)temp;
}
%}

This would remove the problems, by first assigning to a temporary
char* variable. And the standard has exceptions for char*, and
considers it possible for a char* variable to overlap any other
type.

So, to the best of my understanding, the above would actually
prevent a standards complient compiler to do any of the dangerous
optimizations.

However it's not really a "nice" solution, is it?

!g

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 18 00:03:15 2004