Opened 14 years ago

Closed 14 years ago

Last modified 13 years ago

#241 closed defect (fixed)

Fixes for UFFI support

Reported by: hans Owned by: gb
Priority: major Milestone:
Component: Foreign Function Interface Version:
Keywords: Cc:


UFFI uses internal CCL functions, some of which do not work any more:

%set-cstring assumed byte-wide characters

%find-foreign-record first looked for a structure definition, then for a union definition. For unions, it appears that the struct definition that was created for unions was always returned. I reversed the order (first look for a union definition, then for a structure definition for a given name) which fixes the problem for the UFFI test suite. This needs review.

Patch attached.

Attachments (1)

ccl.diff (1.5 KB) - added by hans 14 years ago.
patch to fix both problems in this ticket

Download all attachments as: .zip

Change History (5)

Changed 14 years ago by hans

patch to fix both problems in this ticket

comment:1 Changed 14 years ago by gb

  • Status changed from new to assigned

The %SET-CSTRING issue is clearly a bug, thanks.

The %FIND-FOREIGN-RECORD issue seems to assume that it's meaningful for a struct and a union visible in the same program to share the same tag.

C doesn't seem to think that that's meaningful (or even legal):

[~] gb@dervish> cat foo.h
struct foo {
  int x;
  int y;

union foo {
  int x;
  int y;
[~] gb@dervish> cat foo.c
#include "foo.h"

struct foo f1;
union foo f2;
[~] gb@dervish> cc -m64 -c foo.c
In file included from foo.c:1:
foo.h:6: error: 'foo' defined as wrong kind of tag
foo.c:3: error: 'foo' defined as wrong kind of tag
foo.c:4: error: 'foo' defined as wrong kind of tag

I interpret the first error message to mean that a structure named foo and a union named foo can't coexist meaningfully in a C program (and subsequent error messages as just being consequences of that fact.) It's not clear what it would mean for them to coexist in a lisp program using UFFI, and it doesn't have meaning in CCL (though I suppose that it'd be good to enforce that, and it currently isn't enforced.)

Unless I had a better idea of what that meant (for struct and union types to share the same "tag"), I think that I'd rather enforce the restriction that struct and union types can't share the same tag (as C does) and fail the test. My model is that since C doesn't allow that, no foreign code that one could try to use could depend on being able to refer to structs and unions that (somehow) had the same tag.

comment:2 Changed 14 years ago by hans

I concur, please disregard my suggested change to %FIND-FOREIGN-RECORD. I'll fix UFFI instead.

comment:5 Changed 14 years ago by gb

  • Resolution set to fixed
  • Status changed from reopened to closed

Close this: open ticket:242 for the first (%SET-CSTRING) part

comment:6 Changed 14 years ago by gb

  • Component changed from Infrastructure and Support to Foreign Function Interface
Note: See TracTickets for help on using tickets.