chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Chicken-users] signed-char* not handled correctly


From: Daniel B. Faken
Subject: [Chicken-users] signed-char* not handled correctly
Date: Fri, 22 Jul 2005 12:40:05 -0400 (EDT)

Hello,

  I've been encountering problems using the FFI with functions that take a
(signed char *).  For example, with this short program:
-----------------------
(define-foreign-type GLbyte signed-char)
#>!
typedef signed char GLbyte;
int call_fn(GLbyte x, GLbyte *y);
<#
------------------------
  chicken generates this C stub (fragment):
------------------------
/* from k38 in call_fn in k27 in k24 in k21 */
static C_word C_fcall stub6(C_word C_buf,C_word C_a0,C_word C_a1) 
C_regparm;
C_regparm static C_word C_fcall stub6(C_word C_buf,C_word C_a0,C_word 
C_a1){
C_word C_r=C_SCHEME_UNDEFINED,*C_a=(C_word*)C_buf;
char t0=(char )C_character_code((C_word)C_a0);
char * t1=(char * )C_string_or_null(C_a1);
C_r=C_int_to_num(&C_a,call_fn(t0,t1));
return C_r;}
------------------------
  which causes this compiler error (with csc+gcc on Kanotix/Linux):
tst.c: In function 'stub6':
tst.c:31: warning: pointer targets in passing argument 2 of 'call_fn' 
differ in signedness

This error message is due to the fact that chicken is passing 'char *' 
instead of 'signed char *.  (I guess passing 'char' for 'signed char' is 
silently ignored)
  They are different; according to the GCC man-page:
"""
       -funsigned-char
           Let the type "char" be unsigned, like "unsigned char".

           Each kind of machine has a default for what "char" should be.  It is
           either like "unsigned char" by default or like "signed char" by 
default.

           Ideally, a portable program should always use "signed char" or 
"unsigned
           char" when it depends on the signedness of an object.  But many 
programs
           have been written to use plain "char" and expect it to be signed, or
           expect it to be unsigned, depending on the machines they were written
           for.  This option, and its inverse, let you make such a program work
           with the opposite default.

           The type "char" is always a distinct type from each of "signed char" 
or
           "unsigned char", even though its behavior is always just like one of
           those two.
"""

(and I didn't know this until just now :)

thanks noch einmal,
Daniel






reply via email to

[Prev in Thread] Current Thread [Next in Thread]