C namespace confusion

Bug #1527947 reported by Attila Lendvai
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
CFFI
New
Undecided
Unassigned

Bug Description

so, in C on the toplevel there are two namespaces:

 - main or default (for variables, functions, and typedefs)

 - tagged (for structs, unions, and enums)

details: https://stackoverflow.com/questions/12579142/type-namespace-in-c

a corollary of this is that e.g. you can have a deftype and an enum with the same name.

but CFFI uses a hashtable with conses of the form (namespace . name), but namespace does not correspond to the C namespace rules. namespace can be :struct or :union, and defcenum goes into the :default namespace.

this inconsistency can be observed in e.g. the following:

CL-USER> (cffi:defctype foo :int)
FOO

CL-USER> (cffi::parse-type 'foo)
#<CFFI::FOREIGN-TYPEDEF FOO>

CL-USER> (cffi:defcenum foo)
FOO

CL-USER> (cffi::parse-type 'foo)
#<CFFI::FOREIGN-ENUM FOO>

the reason i'm picky about this seemingly small detail is that having a parallel behavior with the C world is desirable when the binding is generated by a program (that i'm working on), because out in the wild one may find C headers that rely on this behavior, and algorithmic generation of the CFFI binding may lead to subtle bugs.

fixing these should probably involve increasing the major version number as it will break backwards compatibility.

so, to sum it up, i suggest the following:

 - enum's should move into the :tagged namespace, together with struct's and union's. suggested implementation is two separate hashtables for the two C namespaces because we need to be able to detect name clashes between struct/union/enum.

 - enum members should be defined as toplevel constants in the main namespace, just like in C

 - foreign-enum is not a foreign-typedef, stop inheriting from it, and resolve typedefs in foreign-enum-value and friends

 - foreign-bitfield should inherit from foreign-enum, and also not from foreign-typedef

 - redefinition warnings should be added

 - the bare struct/union backward compatibility should be eliminated the sooner the better

i'm open for suggestions, and if this direction is generally desirable then i may write up the necessary patches.

description: updated
description: updated
description: updated
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.