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

lisp error
closed-fixed
ffi (23)
5
2009-10-14
2009-10-07
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
     

Log in to post a comment.

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

Sign up for the SourceForge newsletter:





No, thanks