Re: scratch/igc 3f46110b878: Fix an eassert

[Pip Cet]

"Gerd Moellmann" <gerd@gnu.org> writes:

> branch: scratch/igc
> commit 3f46110b878ef0940ad7c0a9eacd6ef441baad7d
> Author: Gerd Möllmann <gerd@gnu.org>
> Commit: Gerd Möllmann <gerd@gnu.org>
>
>     Fix an eassert
> ---
>  src/igc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/igc.c b/src/igc.c
> index b1ef6939b5f..2ce508e055e 100644
> --- a/src/igc.c
> +++ b/src/igc.c
> @@ -2223,7 +2223,7 @@ fix_weak_hash_table_weak_part (mps_ss_t ss, struct 
> Lisp_Weak_Hash_Table_Weak_Par
>       for (ssize_t i = 0; i < limit; i++)
>         {
>           if (w->entries[i].intptr & 1)
> -           eassert ((mps_word_t)w->entries[i].intptr ^ w->entries[i].intptr 
> == 0);
> +           eassert ((mps_word_t)w->entries[i].intptr ^ (w->entries[i].intptr 
> == 0));
>           bool was_nil = (w->entries[i].intptr) == 0;
>           intptr_t off = 0;
>  #ifdef WORDS_BIGENDIAN

I'm guessing I'm failing a basic C knowledge test here, but can you
explain?  Did you run into an assertion error with the old code, or a
compiler warning?

The intended assertion was that if the .intptr component is truncated to
mps_word_t size, no information is lost, because I saw some problems
with "negative" 32-bit addresses filling the MSB 32 bits of the
Lisp_Objects with ones (the sign extension/zero extension problem, in
other words). That would lead to the "splatted" Lisp_Object reading as
0xffffffff00000000, which caused trouble.

So on i386, the assertion could also be written as

(w->entries[i].intptr & 0xffffffff00000000) == 0

I think the "fixed" assertion is trivially true?

Pip