C interface: wrong types generated?
I don't know if the compiler is generating the wrong type, or i'm doing something wrong... I've written an OpenGL + GLU binding for Gambit-C, which is (I think and hope) 100% done, except for this type error: glColor.c: In function '___H__20_glColor_23_16': glColor.c:1558: warning: pointer targets in passing argument 1 of 'glColor3bv' differ in signedness glColor.c: In function '___H__20_glColor_23_24': glColor.c:1982: warning: pointer targets in passing argument 1 of 'glColor4bv' differ in signedness glNormal.c: In function '___H__20_glNormal_23_5': glNormal.c:563: warning: pointer targets in passing argument 1 of 'glNormal3bv' differ in signedness All three of these mismatched arguments have the same type. Here's the type in C: typedef signed char GLbyte; /* 1-byte signed */ And in Gambit-C: (c-define-type GLbytesigned-char) (c-define-type GLbyte* (pointer GLbyte)) GLAPI void GLAPIENTRY glNormal3bv( const GLbyte *v ); TJay ~
Sorry, hit the Send button before finishing my post... I don't know if the compiler is generating the wrong type, or i'm doing something wrong... I've written an OpenGL + GLU binding for Gambit-C, which is (I think and hope) 100% done, except for this type error:
glColor.c: In function '___H__20_glColor_23_16': glColor.c:1558: warning: pointer targets in passing argument 1 of 'glColor3bv' differ in signedness glColor.c: In function '___H__20_glColor_23_24': glColor.c:1982: warning: pointer targets in passing argument 1 of 'glColor4bv' differ in signedness glNormal.c: In function '___H__20_glNormal_23_5': glNormal.c:563: warning: pointer targets in passing argument 1 of 'glNormal3bv' differ in signedness
~~~~~~~~~~~~~~~ All three of these mismatched arguments have the same type. Here's the type in C: typedef signed char GLbyte; /* 1-byte signed */ And my translation in Gambit-C: (c-define-type GLbyte signed-char) (c-define-type GLbyte* (pointer GLbyte)) ~~~~~~~~~~~ The function declaration in C: GLAPI void GLAPIENTRY glNormal3bv( const GLbyte *v ); And my translation in Gambit-C: (define glColor3bv (c-lambda (GLbyte*) void "glColor3bv")) ~~~~~~~~~~~~ The Gambit-generated C code: .... #define ___NARGS 1 ___BEGIN_CFUN_VOID #define ___ARG1 ___CFUN_ARG(1) ___BEGIN_CFUN_ARG(1,void* ___arg1_voidstar) #define ___arg1 ___CFUN_CAST(___SCHAR*,___arg1_voidstar) ___BEGIN_CFUN_SCMOBJ_TO_POINTER(___ARG1,___arg1_voidstar,___C_OBJ_0,1) ___BEGIN_CFUN_BODY #undef ___AT_END ___CFUN_CALL_VOID(glColor3bv(___arg1)) <--- Wrong type for this. #ifndef ___AT_END #define ___AT_END #endif ___CFUN_SET_RESULT_VOID ___END_CFUN_BODY ___END_CFUN_SCMOBJ_TO_POINTER(___ARG1,___arg1_voidstar,___C_OBJ_0,1) #undef ___arg1 ___END_CFUN_ARG(1) #undef ___ARG1 ___CFUN_ERROR_VOID ___END_CFUN_VOID #undef ___NARGS ___JUMPPRM(___NOTHING,___R0) ___DEF_SLBL(1,___L1__20_glColor_23_16) ___ADJFP(-4) ___JUMPPRM(___NOTHING,___STK(2)) ___END_P_SW ___END_P_COD .... Any ideas what went wrong?
Can you give us a single, self-contained file (no #include's) that has the 8 or so lines of code that triggers the problem? Maybe Marc doesn't need it, but I do ;-). Brad
Can you give us a single, self-contained file (no #include's) that has the 8 or so lines of code that triggers the problem? Maybe Marc doesn't need it, but I do ;-). Brad
;;; Here it is ;) ;;; Built like this on Linux: ;;; > /usr/local/Gambit-C/bin/gsc problem.scm ;;; > gcc -I/usr/local/Gambit-C/include -c problem.c problem_.c ;;; Which gives me the following warnings on gcc 4: -- gcc version 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9) ;;; problem.c: In function '___H__20_problem_23_0': ;;; problem.c:133: warning: pointer targets in passing argument 1 of 'glColor3bv' differ in signedness ;; C type, directly lifted from gl.h (c-declare "typedef signed char GLbyte; /* 1-byte signed */") ;; OpenGL function prototype, placed here directly so as to ;; not required inclusion of gl.h ;; The original prototype, as it appears in gl.h, has some ;; macros attached to it, to specify "extern", or "__stdcall", etc. ;; I've removed it for the sake of keeping this file simple (and ;; uncluttered with C macros. (c-declare "void glColor3bv( const GLbyte *v );") ;; Scheme types. (c-define-type GLbyte signed-char) (c-define-type GLbyte* (pointer GLbyte)) ;; Problem. (define glColor3bv (c-lambda (GLbyte*) void "glColor3bv"))
The problem seems to be in these lines in gambit.h: #if CHAR_MAX == SCHAR_MAX #define ___SCHAR char #else #define ___SCHAR signed char #endif I don't know why Marc thinks he needs these lines; I replaced them with #define ___SCHAR signed char and all was well ... Brad
On 12/27/05, Bradley Lucier <lucier@math.purdue.edu> wrote:
The problem seems to be in these lines in gambit.h:
#if CHAR_MAX == SCHAR_MAX #define ___SCHAR char #else #define ___SCHAR signed char #endif
I don't know why Marc thinks he needs these lines; I replaced them with
#define ___SCHAR signed char
Since defining ___SCHAR as "signed char" fixes things, that suggests that it was defined as "char" before. In turn that means that CHAR_MAX was not equal to SCHAR_MAX. While possible, that's a very odd setup. Can you create a file which contains the following: #include <limit.h> static const a = CHAR_MAX; static const b = SCHAR_MAX; and run 'gcc -E <filename>.c'? The last two lines should give the values of CHAR_MAX and SCHAR_MAX for your system. Generally I would expect them both to be 127. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org 650-283-9641
On 12/27/05, Adam Langley <agl@imperialviolet.org> wrote:
that it was defined as "char" before. In turn that means that CHAR_MAX was not equal to SCHAR_MAX.
Or rather it *was* equal to SCHAR_MAX - ignore me. That's perfectly normal. Bradley just posted the real answer. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org 650-283-9641
I'm not a C language lawyer, but I understand the issue as follows. "char" and "signed char" are distinct types even if they have the same ranges (as they do on tjay and my systems). "char" must behave either like "signed char" or "unsigned char" on any given system, but char, "signed char", and "unsigned char" are three distinct types. On my system SCHAR_MAX and CHAR_MAX are both 127 Brad On Dec 27, 2005, at 4:01 PM, Adam Langley wrote:
On 12/27/05, Bradley Lucier <lucier@math.purdue.edu> wrote:
The problem seems to be in these lines in gambit.h:
#if CHAR_MAX == SCHAR_MAX #define ___SCHAR char #else #define ___SCHAR signed char #endif
I don't know why Marc thinks he needs these lines; I replaced them with
#define ___SCHAR signed char
Since defining ___SCHAR as "signed char" fixes things, that suggests that it was defined as "char" before. In turn that means that CHAR_MAX was not equal to SCHAR_MAX. While possible, that's a very odd setup. Can you create a file which contains the following:
#include <limit.h>
static const a = CHAR_MAX; static const b = SCHAR_MAX;
and run 'gcc -E <filename>.c'? The last two lines should give the values of CHAR_MAX and SCHAR_MAX for your system. Generally I would expect them both to be 127.
AGL
-- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org 650-283-9641
From the GCC manual:
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.
It appears that if Gambit should define SCHAR as "signed char" unconditionally if it doesn't want to get type mismatch warnings with external APIs that use "signed char" explicitly. The specific form of the warning is misleading, however; see the discussion at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23087 Brad
On 27-Dec-05, at 3:46 PM, Bradley Lucier wrote:
The problem seems to be in these lines in gambit.h:
#if CHAR_MAX == SCHAR_MAX #define ___SCHAR char #else #define ___SCHAR signed char #endif
I don't know why Marc thinks he needs these lines; I replaced them with
#define ___SCHAR signed char
and all was well ...
The above fragment of gambit.h is needed to allow some old C compilers which do not support "signed char" to compile Gambit. As I recall Sun' cc compiler on m68k had this problem. I've fixed the problem by replacing that fragment with #ifndef ___SCHAR #define ___SCHAR signed char #endif This should work on modern C compilers, and for old ones the option "- D___SCHAR=char" can be added to the C compiler's command line to compile Gambit. On a related subject, I have added the "wchar_t" type to the FFI (and wchar_t-string, nonnull-wchar_t-string, ...). This is useful for portability (on some C compilers wchar_t is 16 bits and on others it is 32 bits, this is now completely transparent to Scheme code). Marc
participants (4)
-
Adam Langley -
Bradley Lucier -
Marc Feeley -
TJay