[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