Macro inflation [was: Re: change log for rtems (2010-09-08)]
sebastian.huber at embedded-brains.de
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.
>>> On 09.09.2010 15:43, Eric Norum wrote:
>>>> On Sep 9, 2010, at 2:40 AM, Ralf Corsepius wrote:
>>>>> 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.
>>>>> 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
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.
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.
More information about the vc