#535 tests/ffi.tst failures on non-64-bit platforms

lisp error
closed-fixed
Sam Steingold
ffi (23)
5
2009-10-14
2009-10-07
Sam Steingold
No

many tests error out with:
"64 bit integers are not supported on this platform and with this C compiler: SINT64"
there should be a feature test for that

Discussion

  • Sam Steingold
    Sam Steingold
    2009-10-07

    we already have a word-size=64 feature (enabled when WIDE_HARD is defined), so
    #+word-size=64 is enough to fix this specific failure (since WIDE_HARD ==> HAVE_LONG_LONG_INT).
    however, there are situations when words are 32-bit, but FFI can handle 64-bit ints.
    Should we add an FFI-64BIT feature?

     
  • Sam Steingold
    Sam Steingold
    2009-10-08

    <http://article.gmane.org/gmane.lisp.clisp.devel/21011>
    from Jorg:

    I dislike #+features, because that causes .fas file to cease to be shareable among machines. There could be a huge, otherwise portable .fas file, which causes mysterious failures for no other reason that a single #+64bit in the source, whereas others, like #+clisp of course cause no harm.

    For the needs ffi.tst, (ignore-errors (parse-c-type 'ffi:uint64)) could be enough? Or another instance of
    (ignore-errors
    (def-call-out "ffi_identity" ... uint64)
    (funcall pseudo-identity 0))

    This raises the question about
    a) whether the FFI:UINT64 should exist in all cases
    I say yes because it causes package issues otherwise.
    b) whether parse-c-type accepts ffi:uint64 even though the C does not support it.
    No seems resonable. However:

    What about cross compilation? Shouldn't I be able to compile a .fas file on one machine and execute it on another one?
    I'd say yes. So errors should only appear at run-time, trying to invoke the function??

    There could be compiler constant folding issues with .fas files. I remember one optimization that turns (parse-c-type 'ffi:uint) into 'uint. So the runtime must be prepared to get called with an uint46 internal-c-type even ffcall or the C compiler does not support it, and error out (I'm sure it does).

     
  • Sam Steingold
    Sam Steingold
    2009-10-08

    thank you for your bug report.
    the bug has been fixed in the CVS tree.
    you can either wait for the next release (recommended)
    or check out the current CVS tree (see http://clisp.cons.org\)
    and build CLISP from the sources (be advised that between
    releases the CVS tree is very unstable and may not even build
    on your platform).

     
  • Sam Steingold
    Sam Steingold
    2009-10-08

    I decided to disable the 64-bit tests on non-WIDE_HARD platforms (so that the tests pass on all platforms)
    but not to introduce a special conditional so that cross compilation is preserved.
    you have 2 weeks to complain here, after that the bug will be closed.

     
  • Sam Steingold
    Sam Steingold
    2009-10-08

    • assigned_to: hoehle --> sds
    • status: open --> pending-fixed
     
  • Jörg Höhle
    Jörg Höhle
    2009-10-09

    >I decided to disable the 64-bit tests on non-WIDE_HARD platforms
    >(so that the tests pass on all platforms)
    If I understood right, you don't test uint64 on the typical 32bit Linux machine anymore?
    I think this is a bad move. Running tests is important -- everywhere.

    Why not use something like
    (devar available (ignore-errors ...detector...))
    available

    (if available ...testx... #| else precomputed value |# 64)
    64
    (if available ...testy... T)
    T

     
  • Sam Steingold
    Sam Steingold
    2009-10-09

    feel free to propose the "...detector..." code

     
  • Sam Steingold
    Sam Steingold
    2009-10-09

    • status: pending-fixed --> open-fixed
     
  • Sam Steingold
    Sam Steingold
    2009-10-14

    • status: open-fixed --> pending-fixed
     
  • Sam Steingold
    Sam Steingold
    2009-10-14

    I can no longer reproduce this on woe32 (somehow HAVE_LONG_LONG_INT is now defined) so I don't know what platforms need this.
    reverting the patch.

     
  • Sam Steingold
    Sam Steingold
    2009-10-14

    • status: pending-fixed --> closed-fixed