[kaffe] Suspicious changes

[Dalibor Topic]

Gwenole Beauchesne wrote:
> Hi,
> 
> While tracking down my regressions on x86_64, I came accross the 
> following (unrelated) problem:
> 
> 2004-03-24  Dalibor Topic <robilad at kaffe.org>
> 
>         * kaffe/kaffevm/support.c,
>         libraries/clib/net/PlainSocketImpl.c:
>         Fixed remaining 'foo' is not defined warnings.
> 
> which, for this problem, looks like:
> 
> @@ -384,7 +384,7 @@ execute_java_constructor(const char* cna
>     be marked as 'D'.  No known port uses this.  In fact, alpha must
>     explicitly set it to 0, to prevent PROMOTE_TO_64bits from enabling
>     it.  */
> -#if PROMOTE_jfloat2jdouble
> +#if defined(PROMOTE_jfloat2jdouble)
>  # define PROM_f d
>  #else
>  # define PROM_f f
> 
> My interpretation of the C standard tells that in "#if FOO", if FOO is 
> not defined, it will yield 0. Besides, "#if defined(FOO)" will yield 
> true even if FOO is defined to 0.
> 
> Thus, since I had #define PROMOTE_jfloat2jdouble 0 in 
> config/x86_64/sysdepCallMethod.h, Kaffe will do jfloat to jdouble 
> promotion, which is not wanted.

Argh, good catch. Thanks a lot for spotting that one.

> I could remove that definition from x86_64 sysdepCallMethod.h, but that 
> would IMHO still hide the bug that you now check for the macro being 
> defined instead of its actual value. I believe this is why I see 
> Double*.java regressions [when using an x86 built rt.jar].

I prefer to check if the macro is defined, instead of checking for 
value. I didn't realize that PROMOTE_jfloat2jdouble could be 0, though :(.

Looking at the GNU Coding Standards, I see that there is an entry on 
that: http://www.gnu.org/prep/standards_11.html#SEC11

So how about turning the code using  PROMOTE_jfloat2jdouble in 
kaffe/kaffevm/support.c into if() {} else {} blocks as the GNU docs suggest?

cheers,
dalibor topic