Bruno Haible wrote:
>> #define _GL_CONCAT0(x, y) x##y
>> #define _GL_CONCAT(x, y) _GL_CONCAT0 (x, y)
>> - extern struct {...} * _GL_CONCAT(dummy,__LINE__);
>> + extern struct {...} * _GL_CONCAT (dummy, __LINE__);
>>
>> But this has the problem that two invocations of verify from
>> within the same macro would collide, since the __LINE__ value
Hi Bruno,
> I have no objection against this patch. Just a note that my personal
> preference is to emphasize the token-pasting effect of such macros
> by _not_ putting spaces there. See
> <http://lists.gnu.org/archive/html/bug-gnulib/2010-03/msg00257.html>
Yes, I remember that.
However, note that the unmodified _GL_CONCAT0 use just above was
already formatted the way an automatic tool might have done, given our
general preference (though this is in a comment after all).
I understand your preference, but doubt I would ever adopt such a
practice unless I find a tool that is sufficiently aware of semantics
to automatically perform the job. Maybe not even then. I'm not sure
I would want to let a change in semantics (token-paste-or-not), however
unlikely, evoke a global change in formatting.
