[U-Boot] [RESEND PATCH v2 1/5] Tegra2: Add macros to calculate bitfield shifts and masks

[Anton Staaf]

On Tue, Jul 12, 2011 at 8:29 AM, Albert ARIBAUD
<albert.u.boot at aribaud.net>wrote:

> Hi Anton,
>
> Le 11/07/2011 18:19, Anton Staaf a écrit :
>
>
>  I know that this is throwing more fuel on the fire (for which I am sorry),
>> but I don't follow the argument that this is unportable.  As far as I can
>> tell, the # : # syntax is not using any special compiler extensions, it is
>> simply substituted into a (boo) ? # : # expression, thus extracting either
>> the first of second number from the definition of the bit field.
>>
>> If I am wrong I would be interested to know what about this is not
>> standard
>> pre-processor usage?
>>
>
> For me at least (Wolfgang might have other reasons), the issue is not the
> use of the pre-processor per se, it is that this "syntax" breaks the '?:'
> "triadic" operator in pieces, one piece in argument value and one in macro
> body, and neither piece makes sense from a C standpoint: '5:3' represents no
> meaningful C entity, and 'X ? y' (without the ':' and third argument of the
> operator) is not a proper C construct.
>

Yes, this is absolutely true, and we can argue about readability vs.
usability vs. maintainability of such a construct (I like it, but I realize
that I might be in a minority here).  But it is certainly portable, there is
nothing compiler or pre-processor specific here.  I just wanted to clarify
that so that we could have the correct debate.  :)

IOW, it is syntactic sugaring done at the expense of code readability.
>

I would disagree here, it is indeed syntactic sugar, but I would assert that
it is done exactly to make the code more readable.  The one piece of macro
magic is in a single file that can be well documented and encapsulated.  I
find having one #define that specifies the entire range much easier to read
and debug than having two #defines, one for each end of the range that you
have to make sure are matched.  And this simplification can be applied to
many many files.  But that's what it really boils down to, what we each find
easier to read and debug.  I'm fine if the decision is that everyone else
doesn't like the way this reads, but let's not throw it out based on a
compatibility argument that is invalid.

Thanks,
    Anton

 Thanks,
>>     Anton
>>
>
> Amicalement,
> --
> Albert.
>