#217 Lifelines not 64 bit clean



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().



  • Matthew Emmerton

    • assigned_to: nobody --> memmerto
  • Matthew Emmerton

    Logged In: YES

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

    Dr. Werner Fink - 2008-01-04

    Logged In: YES
    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
    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
    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.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks