#217 Lifelines not 64 bit clean

[Dr. Werner Fink]

Hi,

even on 64 bit systems src/hdrs/standard.h defines
INT to int and not to intptr_t or uintptr_t provided
by the system header <stdint.h>. Beside this
there are mixed function pointers with object
pointers which is not ISO C standard. Beside
this gcc requires -fno-strict-aliasing to avoid
warning about lines like

return (INT *)&pvalue(val);

from src/interp/pvalue.c : pvalue_to_pint().

Werner

[Matthew Emmerton]

Logged In: YES
user_id=61514

intptr_t or uintptr_t are not appropriate for INT, as they
describe integer POINTERS, not plain integer values.

The proper portable declaration would fix INT to a
particular bit width; likely int32_t is the best choice for
this code.

I will look into the mixed function pointer issues -- here
intptr_t/uintptr_t are more appropriate, and we should have
an 'int pointer' type defined locally.

[elsapo]

Logged In: YES
user_id=1195173
Originator: NO

pvalue_to_pint is gone.

PVALUE now uses a real union.

But, the word1, word2 etc in the pnode union still mix pointers and ints.

[Dr. Werner Fink]

Logged In: YES
user_id=547210
Originator: YES

I suggest to use `long` instead of `int' (or `unsignend long` instead of `unsigned int')
this type is normaly of the same size as the pointers addresses are. This would allows
to mix pointers and longs on 32bit and also on 64bit. Only if binrary data is dumped out
one can not read 64bit dumps on a 32bit system and vice versa.

[Matthew Emmerton]

Logged In: YES
user_id=61514
Originator: NO

We won't be using long in any LifeLines code. Even though it's *normally* the same as pointer addresses, it isn't guaranteed by any standard.

As previously discussed on the development mailing list, we will be using generic 'int' where actual bounds is not a problem (ie, loop iterators, etc), and will be using fixed-width types (such as 'int32_t' or 'int64_t') for on-disk structures and variables that need to have known, fixed limits on range.

The constructs that require the use of -fno-strict-aliasing are slowly going away as we clean up the code in the interpreter to use proper types throughout, instead of relying on magic casts to "just work". Myself and elsapo cleaned up the PVALUE construct over the last two years, and now elsapo is working on cleaning up the PNODE construct.

[elsapo]

Logged In: YES
user_id=1195173
Originator: NO

Yes, I think the safest way to move pointers and integers through the same variable is to use a union, because that is the strongest guarantee that it will fit both pieces of data. The PVALUE data now uses such unions, and the interpeter data (PNODEs) are moving towards that.