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