[Top][All Lists]
[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
- [Chicken-users] signed-char* not handled correctly,
Daniel B. Faken <=