#217 Lifelines not 64 bit clean

Feature_Request
open
None
5
2005-11-19
2005-09-30
Dr. Werner Fink
No

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

Discussion

    • assigned_to: nobody --> memmerto
     
  • 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
    elsapo
    2008-01-04

    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.

     
  • 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.

     
  • 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
    elsapo
    2008-01-05

    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.