[ECOS] Re: Namespace pollution
Tue Mar 4 15:17:00 GMT 2003
Gary D. Thomas wrote:
> I've run into a problem [near and dear to your heart]
You know me so well ;).
> - a place where
> the eCos namespace (via include files) intrudes on an application. The
> problem is in <pthread.h>. This particular application happens to have
> a typedef for the symbol "destructor", which causes this prototype to
> // Create a key to identify a location in the thread specific data area.
> // Each thread has its own distinct thread-specific data area but all are
> // addressed by the same keys. The destructor function is called whenever a
> // thread exits and the value associated with the key is non-NULL.
> externC int pthread_key_create (pthread_key_t *key,
> void (*destructor) (void *));
> So, the question(s) are:
> * Who's at fault here? (the application or the kernel)
The kernel. "destructor" isn't in the name space.
> * How best to solve it?
People argue a lot about the best way :-). Some say to just drop the
argument name entirely and just have the types, but that makes reading the
header file more difficult. Some say "uglify" it with e.g. __key and
__destructor (and two underscores are slightly better in general if you
read the C standard), although in a component based system even that can
have problems.... for example we have several definitions of __string
floating around as stringify macros in several files. I've had to check in
patches to try and resolve that a little before!
The remaining option is to use C comments, e.g.
externC int pthread_key_create (pthread_key_t * /* key */,
void (* /* destructor */ ) (void *));
although as you can see it makes it slightly more difficult to parse
visually with pointers around.
None of the options are good. I've tended to opt for the latter more
recently though as least likely to cause problems in the future at the
expense of readability, but at least not without losing the
Of course "externC" breaks namespacing too, and I definitely want to move
everything to __externC at some point (and split cyg_type.h into something
more fine-grained). If you're there, it wouldn't be terrible if you could
do that too ;).
> (Yes, I know I'm responsible for a number of similar issues. What
> I'm interested in here is how we should fix them :-)
I've been casual too! I certainly was when I started eCos stuff those many
years ago. There's code out there I'm embarassed to have my name against!
If only I had the time to rewrite it all ;-).
eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[ can rejoice because thorns have roses." -Lincoln ]-- Opinions==mine
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
More information about the Ecos-discuss