[cfe-commits] [Request for approval] Warning for recursive macro expansion attempt

Douglas Gregor dgregor at apple.com
Sun Jan 1 10:32:59 PST 2012

On Jan 1, 2012, at 10:23 AM, Abramo Bagnara wrote:

> Il 01/01/2012 18:56, Douglas Gregor ha scritto:
>> On Dec 22, 2011, at 10:32 AM, Abramo Bagnara wrote:
>>>> The attached patch add a warning (disabled by default) to show the
>>>> (mostly unwanted) attempt to recursively expand a macro.
>>>> Ok to commit?
>> I'm having a hard time understanding the motivation behind this warning, because I've never encountered a place where it would have helped find a problem. On the other hand, I've seen a number of macros that wrap functions (with the same name) that benefit from the suppression of recursive macro instantiations, and those would come up as false positives with this warning.
> As you write there might be legitimate needs for that detail of C
> preprocessor behavior (and this is the reason why I've left it disabled
> by default), but there are coding standars that prohibits that, e.g.
> NASA JPL Institutional Coding Standard for the C Programming Language at
> page 16 of
> http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf
> is written:
> "Rule 20 (preprocessor use)
> Use of the C preprocessor shall be limited to file inclusion and simple
> macros.
> ...
> Specifically, the use of token pasting (cf. MISRA-C:2004 Rules 19.12 and
> 19.13), variable argument lists (ellipses) (cf. MISRA-C:2004 Rule 16.1),
> and recursive macro calls are excluded by this rule. All macros are
> required to expand into complete syntactic units (cf. MISRA-C:2004 Rule
> 19.4)."
> Implementing this check using clang library is very hard (if not
> impossible) and this is the reason why I've proposed to add this warning.

Yeah, this is extremely hard to implement as a library, and JPL's coding standards carry some weight in the community. Thanks.

Please go ahead and commit.

	- Doug

More information about the cfe-commits mailing list