Macro inflation [was: Re: change log for rtems (2010-09-08)]

Sebastian Huber sebastian.huber at
Fri Sep 10 08:01:46 UTC 2010

On 09/10/2010 09:46 AM, Ralf Corsepius wrote:
> On 09/10/2010 09:18 AM, Sebastian Huber wrote:
>> On 09/10/2010 08:45 AM, Thomas Dörfler wrote:
>>> Eric, Ralf,
>>> obviously we have different opinions here. Once again: I agree that a
>>> different namespace is required for these definitions, but I think the
>>> macros _do_ improve readability.
>>> I would like to move the discussion back to the rtems-vc mailing list to
>>> allow Sebastian to express his opinions.
>>> wkr,
>>> Thomas.
>>> On 09.09.2010 15:43, Eric Norum wrote:
>>>> On Sep 9, 2010, at 2:40 AM, Ralf Corsepius wrote:
>>>>> Hi,
>>>>> Sebastian Huber committed the patch to CVS, yesterday.
>>>>> Unfortunately nobody so far has responded to my remark.
>>>>> Therefore, I don't see another alternative but to bring this to the
>>>>> attention of the SC.
>>>>> Rationale:
>>>>> a) this patch is bad code and must be removed.
>>>>> The macros are not namespace safe and thus are likely to clash with
>>>>> other macros. E.g. using a macro called BIT8 is grossly negligant.
>> Yes, it is not name space safe.  There is no reason for this.
> Rubbish. Your file is a global header and can be included from any
> source file anywhere. It's mere random lack these macros currently don't
> conflict.

It is not present by default.  The BSP has to add it to its  It is
also no random luck that we don't have a conflict.

>> This file is
>> intended to simplify the description of flags and fields from hardware
>> registers.  These definitions are only useful for a limited scope.  If
>> you put
>> the hardware dependent definitions into a wider scope, e.g. via bsp.h
>> you do
>> something wrong.
>> Also preprocessor stuff doesn't show up in the symbol table.
> Symbol tables are not of any relevance here.
> The probem is the code such macros produce after preprocessing and the
> issues such macros introduce when going after bugs.

This is a bit vague.  Which macro produces problematic code?

> These are very specialized _private_ macros.

Yes, exactly.  This is the use case for the <bsp/utility.h>.

> What you did, is to add global macros to a global header.
> Ralf

What is your definition of a global header?  Installed header files in
<bsp/*.h> are not global from my understanding.

Sebastian Huber, embedded brains GmbH

Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone   : +49 89 18 90 80 79-6
Fax     : +49 89 18 90 80 79-9
E-Mail  : sebastian.huber at
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

More information about the vc mailing list