Re: regression in autoconf-2.62 vs. 2.61

[Eric Blake]

Stepan Kasal <skasal <at> redhat.com> writes:

> First, let me state that, strictly speaking, this is not a
> regression.  The Autoconf manual says that the #undef line cannot
> contain anything after the symbol.   And in that case, all versions
> tested by Ralf do the same.

I agree that whether or not we change code, a doc patch is necessary.  But I'm 
still interested to see if Ralf's patch to restore saner behavior proves 
worthwhile, before deciding whether your proposed doc patch is right.

> 
> Does anyone know whether comments on #undef lines and #define lines
> are portable?

I just checked the standard.  They'd better be portable, or your preprocessor 
is buggy.  Even in C89 2.1.1.2, comments are stripped in phase 3, then 
preprocessing tokens acted on in phase 4.  C89 3.8 reminds that arbtrary 
amounts of space, including those substituted from original comments, can occur 
between preprocessing tokens.  And based on the volume of existing code base 
that does

#endif /*foo*/

I can't imagine a preprocessor that mishandles

#undef foo /*comment*/

(although I could always be proven wrong by an actual counterexample from a 
vendor with a buggy preprocessor :)

>  I always thought that #undef comments were not
> portable and #define comments could at least became part of the body
> of the macro definition.

Actually, the entire comment is supposed to be replaced by a single space in 
the body of the macro.  Prior to C89, though, a comment in a #define was the 
only way to do token pasting.

>  I thought this were the reason why these
> comments were generally frown upon.

Comments in the config.h template file are different than normal C comments, in 
the sense that we are passing them through yet another set of tools (formerly 
sed, now awk) to create a valid C89 header file.  So I think the autoconf 
restriction of no comments, above and beyond the C89 requirements, is more for 
making our template conversion easy, than for avoiding invalid code.

> If that were true, than I would prefer deleting the rest of the line
> after #undef since it might make the resulting header more portable.

Based on the standard,

#undef foo /* comment
*/

is valid, but stripping the end of the line produces

/* #undef foo */
*/

which is not.

> 
> About the case of #undef OTHER_SYMBOL being commented out, I suggest
> to preserve that behaviour, or someone will get trapped by that
> change and report a regression.  

I could go either way on this one.  But whichever we decide (leaving 
OTHER_SYMBOL commented out, as currently done, or leaving it unmolested, as the 
OP requested) should be documented and tested prior to the 2.63 release.

-- 
Eric Blake