name clash question

Ralf Corsepius corsepiu at faw.uni-ulm.de
Fri Aug 10 04:41:00 UTC 2001


Am 09 Aug 2001 11:54:03 -0700 schrieb Till Straumann:
> I found (while compiling EPICS-base under RTEMS) that many rtems
> include files define a macro
> 
> #define delay( )  something
> 
> One of these found its way through installation into libcpu/cpu.h
> 
> Obviously, this leads to obscure compiling errors in an application
> that does e.g.
> 
> #include <rtems.h> /* implicitely includes libcpu/cpu.h with delay
> macro */
> 
> static int delay(void)
> {
> /* do something */
> }
Hmm, non-portable application code design ;)

On some OSes/toolchains, "delay" is an OS/toolchain-supplied function
(IIRC, several M$-toolchains supply "delay").

> Is the existence of the "delay" macro an RTEMS "feature" or should the
> namespace be cleaned up?
IMHO, the latter. This has nagged me several times before :)

I would suggest that the current "delay" (a spin-delay) should be
renamed into
<bsp>_delay (Marking it bsp-proprietary)
or
<cpu>_delay (Marking it cpu-proprietary)
or
rtems_delay (Rendering it into an official part of RTEMS's API)

I am not sure which alternative would be best. The easiest solution to
implement would be <bsp>_delay.

Ralf





More information about the users mailing list