Re: [Chicken-janitors] #1005: mmap test doesn't correctly catch error situations (was: pointer data structures don't overflow reliably, also this does not catch mmap error situations)

[Chicken Trac]

#1005: mmap test doesn't correctly catch error situations
----------------------+--------------------------------------
  Reporter:  ckeen    |      Owner:
      Type:  defect   |     Status:  reopened
  Priority:  major    |  Milestone:  someday
 Component:  unknown  |    Version:  4.8.x
Resolution:           |   Keywords:  mmap ffi pointer suckage
----------------------+--------------------------------------
Description changed by sjamaan:

Old description:

> I have just came across this issue when dealing with a failed mmap FFI
> call. In this case mmap (The C function) will return a MAP_FAILED which
> is defined as (void*)-1 on linux and OpenBSD.
>
> The mmap code checks for this by doing a (eq? -1 addr2). This is fine for
> 32 bit systems but not for 64 bit systems.
>
> {{{
> ;; on 32 bit
> #;2> (address->pointer -1)
> #<pointer 0xffffffff>
>
> ;; on 64 bit
> #;2> (address->pointer -1)
> #<pointer 0x0>
> #;3> (pointer->address #2)
> 1.84467440737096e+19
> }}}
>
> Note how the pointer printing code also gets it wrong.
>
> A current workaround would be to explicitly check for the -1 pointer
> representation:
>
> {{{
> (pointer=? (address->pointer -1) addr2)
> }}}
>
> This works but looks icky. I am not sure how to handle this right.

New description:

 I have just came across this issue when dealing with a failed mmap FFI
 call. In this case mmap (The C function) will return a MAP_FAILED which is
 defined as (void*)-1 on linux and OpenBSD.

 The mmap code checks for this by doing a (eq? -1 addr2). This is fine for
 32 bit systems but not for 64 bit systems.

 {{{
 ;; on 32 bit
 #;2> (address->pointer -1)
 #<pointer 0xffffffff>

 ;; on 64 bit
 #;2> (address->pointer -1)
 #<pointer 0x0>
 #;3> (pointer->address #2)
 1.84467440737096e+19
 }}}

 Note how the pointer printing code also gets it wrong. **this has been
 fixed in CHICKEN 5: it will now correctly print the pointer's address,
 interpreted as an unsigned number.**

 A workaround would be to explicitly check for the -1 pointer
 representation:

 {{{
 (pointer=? (address->pointer -1) addr2)
 }}}

 This works but looks icky. I am not sure how to handle this right.

--

--
Ticket URL: <http://bugs.call-cc.org/ticket/1005#comment:5>
CHICKEN Scheme <http://www.call-cc.org/>
CHICKEN Scheme is a compiler for the Scheme programming language.