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

[Sebastian Huber]

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 Makefile.am.  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 embedded-brains.de
PGP     : Public key available on request.

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