This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Namespace pollution
- From: Jonathan Larmour <jifl at eCosCentric dot com>
- To: "Gary D. Thomas" <gary dot thomas at mind dot be>
- Cc: eCos Discussion <ecos-discuss at sources dot redhat dot com>
- Date: Tue, 04 Mar 2003 15:16:51 +0000
- Subject: [ECOS] Re: Namespace pollution
- References: <1046787784.6490.2046.camel@hermes.chez-thomas.org>
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