txr-users
[Top][All Lists]
Advanced

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

Re: [Txr-users] txr segfaults on startup, Mac OSX 10.6


From: Kaz Kylheku
Subject: Re: [Txr-users] txr segfaults on startup, Mac OSX 10.6
Date: Mon, 05 Dec 2011 22:46:07 -0800
User-agent: Roundcube Webmail/0.4

Hi Andy,

Thanks for diagnosing this.

> Included.  config.h looks pretty suspicious when it does a 1 << 78 while
> building INT_PTR_MAX.  You know what a more reasonable value would be?  62?

The 1 << 78 is totally wrong. It must not be wider than two
bits less than the width of the type. Because of this, INT_PTR_MAX,
NUM_MIN and NUM_MAX are garbage values, and the program is DOA.

62 is the right value. 78 would be right if you had 80 bit pointers,
and 80 bit integers to go with them.

On my x86_64 system, here is what INT_PTR_MAX looks like:

#define INT_PTR_MAX (((((long) 1 << 62) - 1) << 1) + 1)

The trick here is to compute the highest value of a signed 64
bit type (i.e. 63 all one bits) in a way that reduces to
a compile-time constant, and doesn't overflow.

So first we compute 1 followed by 62 0's. When we subtract 1,
we get 62 1's.  Then we shift it left and plug the 0 bit.

Based on this quantity, we can compute NUM_MIN and NUM_MAX:
the range of numbers we can store in a cell, taking into
account that we need two bits for type information.

Anyway, the test suite passing is a good sign.

>  I was looking for problems in the Makefile -- I forgot that autoconf
> builds config.h as well...

P.S.   No Autoconf is used here! I wrote all the scriptology
by hand, but conforming to the way some key things are named
in Autoconf. :)

As a result, the configure script isn't some scary monstrosity
generated by GNU m4 macros, but something understandable.

Cheers ...






reply via email to

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