[ECOS] Namespace pollution

Gary D. Thomas gary.thomas@mind.be
Tue Mar 4 14:23:00 GMT 2003


Jonathan,

I've run into a problem [near and dear to your heart] - 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)
 * How best to solve it?

As a work-around, I've modified that particular include file 
to avoid this problem (renaming destructor as _destructor).  

n.b. This is a portable application from outside the eCos world,
so I don't want to have to change it, if possible.  If, on the
other hand, this is truly an application issue, I'll gladly take
it up with the [application] maintainers.

Thanks.

(Yes, I know I'm responsible for a number of similar issues.  What
I'm interested in here is how we should fix them :-)

-- 
.--------------------------------------------------------.
|       Mind: Embedded Linux and eCos Development        |
|--------------------------------------------------------|
| Gary Thomas              email:  gary.thomas@mind.be   |
| Mind ( http://mind.be )  tel:    +1 (970) 229-1963     |
| gpg: http://www.chez-thomas.org/gary/gpg_key.asc       |
'--------------------------------------------------------'


-- 
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 mailing list