[ECOS] Re: Namespace pollution

[Jonathan Larmour <jifl at eCosCentric dot com>]

Gary D. Thomas wrote:
> Jonathan,
>
> 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 
> fail:
>
> // 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 
"documentation" aspect.

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 ;-).

Jifl
--
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