| 2015-12-20 00:11:16 |
Attila Lendvai |
bug |
|
|
added bug |
| 2015-12-23 20:47:12 |
Attila Lendvai |
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.
- 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. |
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
- 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. |
|
| 2015-12-25 21:51:33 |
Attila Lendvai |
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
- 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. |
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
- 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. |
|
| 2015-12-25 22:10:24 |
Attila Lendvai |
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
- 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. |
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. |
|
