[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
name clash question
- Date: 10 Aug 2001 06:41:00 +0200
- From: corsepiu at faw.uni-ulm.de (Ralf Corsepius)
- Subject: name clash question
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
<bsp>_delay (Marking it bsp-proprietary)
<cpu>_delay (Marking it cpu-proprietary)
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.