After reading #1005, I was trying to understand what was going on that accounts
for the -1 result in 32 bit systems vs. 0 under 64 bit OS.
Attempting to learn about it, I ran a scheme program using the mmap API
directly--the relevant lines are:
(define mmap-long (foreign-lambda* long ((integer len) (int prot) (int fd))
#<<EOP
#include <sys/mman.h>
#include <stdio.h>
/* using only MAP_FILE guarantees failure--return -1 */
char *r = (char*) mmap (NULL, len, prot, MAP_FILE, fd, 0);
long n = (long) r;
/* print out the C pointer and cast to long int */
printf( "C. mmap output: (void*): %p (long): %ld\n", r, n);
C_return(n);
EOP
))
(define int->c-ptr (foreign-lambda* c-pointer ((long n))
#<<EOP
char *p = (char *) (void*) n;
double d = (double) (unsigned long) n;
/* input int cast to pointer, and printed in exp format */
printf ("C. Input (long): %ld (long*): %p (ulong): %e\n",
n, p, d);
C_return(p);
EOP
))
;; text file opened ...
(print "fd " fd)
(define int-res (mmap-long 5 1 fd)) ;; returns address as long
(define ptr-res (int->c-ptr int-res)) ;; returns -1 as "c-pointer"
(printf "SCM FFI: mmap-long: ~a int->c-ptr: ~a addr: ~a\n"
int-res ptr-res (pointer->address ptr-res))
The output was:
fd 3
C. mmap output: (void*): 0xffffffffffffffff (long): -1
C. Input (long): -1 (long*): 0xffffffffffffffff (ulong): 1.844674e 19
SCM FFI: mmap-long: -1 int->c-ptr: #<pointer 0x0> addr: 1.84467440737096e 19
This looks exactly like the prior results. The pointer object reports 0 rather
than -1, but curiously, (pointer->address) seems to correctly dereferences the
result (-1), though obscurely prints the unsigned long in exponential format.
It appears something happens in setting/getting the data member of the pointer
object scheme-block structure. That code is kind of convoluted, and I don't
yet understand it well enough to comment further.
BTW, during another scheme test using (foreign-lambda ...), there was a warning
during compilation:
mmap.c: In function âstub88â:
mmap.c:36:30: warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
referring to mmap.c:
..
34 int t4=(int )C_unfix(C_a4);
35 int t5=(int )C_num_to_int(C_a5);
36 C_r=C_mpointer_or_false(&C_a,(void*)mmap(t0,t1,t2,t3,t4,t5));
37 return C_r;} ^36:30
Not at all sure where that comes from, but maybe it's a clue to the reported 32
vs 64 bit differences.
Long-winded I know, but I'm wondering if mmap is the only c-pointer that's
affected, and if not, is it causing trouble elsewhere?
Jules Altfas.
> On Fri, 12 Apr 2013 09:22:44 0200, Christian Kellermann
> <[email protected]> wrote:
> Just a quick follow up, I have posted a similar patch to chicken-hackers.
>
> Thanks for your help!
>
> Christian
>
> --
> In the world, there is nothing more submissive and weak than
> water. Yet for attacking that which is hard and strong, nothing can
> surpass it. --- Lao Tzu
>_______________________________________________
Chicken-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/chicken-users
