emacs-pretest-bug
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: warnings compiling Emacs 22 on amd64


From: Eli Zaretskii
Subject: Re: warnings compiling Emacs 22 on amd64
Date: Mon, 11 Dec 2006 22:41:51 +0200

> Date: Mon, 11 Dec 2006 13:43:17 +0100
> From: Francesco Potorti` <address@hidden>
> Cc: address@hidden
> 
> The reason why those warnings are there is that a comparison is made
> between an int (32 bits) or a short (16 bits) and a constant long (64 bits).

Are you talking about the comparison in FIXNUM_OVERFLOW_P?  If so,
where's the 32-bit int and the 64-bit long in that macro?  I must be
missing something, because what I see there is a comparison between
two values which are both cast to EMACS_INT, which makes them both of
type long.

> Such a comparison is useless, because the compiler knows that the
> constant long is always bigger than the int, due to its size.  I tried
> to avoid the comparison by changing the FIXNUM_OVERFLOW_P macro like
> this:
> 
> #define FIXNUM_OVERFLOW_P(i) \
>   (sizeof(i) >= sizeof(EMACS_INT) \
>    && ((EMACS_INT)(i) > MOST_POSITIVE_FIXNUM \
>        || (EMACS_INT)(i) < MOST_NEGATIVE_FIXNUM))
> 
> that is, by adding a test on sizeof at the beginning.  However, this has
> no effect and the following warnings are always there:

If FIXNUM_OVERFLOW_P should always return zero on 64-bit machines,
then how about changing FIXNUM_OVERFLOW_P so that it's a constant on
64-bit machines?  For example:

  #ifdef _LP64
  # define FIXNUM_OVERFLOW_P(i) 0
  #else
  # define FIXNUM_OVERFLOW_P(i) \
     ((EMACS_INT)(i) > MOST_POSITIVE_FIXNUM \
      || (EMACS_INT) (i) < MOST_NEGATIVE_FIXNUM)
  #endif

Does this fix the problem?

(But I still would like to understand why the comparison is always
true.)

> Doing like this:
> 
> #define FIXNUM_OVERFLOW_P(i) \
>   ((sizeof(i) < sizeof(EMACS_INT)) ? 0 \
>    : ((EMACS_INT)(i) > MOST_POSITIVE_FIXNUM \
>        || (EMACS_INT)(i) < MOST_NEGATIVE_FIXNUM))
> 
> still changes nothing.  Apparently the compiler runs the second test
> even if the first one fails, and so issues a warning.

I don't think the code is ``run'', but it is definitely analyzed by
the parser, and that is when you get the warning.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]