This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Expand mempcpy into memcpy


On 2/6/2013 1:21 PM, Paul Eggert wrote:
> On 02/06/13 10:12, Chris Metcalf wrote:
>> just following the standard rule of "parenthesize the use of all macro arguments"
> But we don't follow that rule.  If we did, we'd have to
> write macro definitions like this:
>
>   #define foo(x, y) bar ((y), (x))
>
> with the extra parentheses; which we typically don't do.

No, you're right - passing from one macro to another is always an exception, since you can't screw up the precedence.  If you could pass it in from the top level macro, you can pass it on to the next macro definition.

But yes, it's a fair point that the "rule" is not ironclad.

> Of course it's a minor point.  There's a style where one always
> parenthesizes the operand of "return", e.g., "return (x);".
> For people used to that style, it's weird to see "return x;" and
> at first it looks like a mistake.  But one gets used to it...

Yes - that one is less clear-cut.  I omit the parentheses because they seem like syntactic clutter, but I don't think there's a real argument to be made either way; it's just a question of the style that looks prettiest to each person.   (I do use parentheses for the arguments of "sizeof" and "defined", so I'm not consistently minimalist!)

-- 
Chris Metcalf, Tilera Corp.
http://www.tilera.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]