[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] gettext: do not assume '#define ... defined ...' behavior
From: |
Bruno Haible |
Subject: |
Re: [PATCH] gettext: do not assume '#define ... defined ...' behavior |
Date: |
Thu, 12 Jul 2012 12:15:56 +0200 |
User-agent: |
KMail/4.7.4 (Linux/3.1.10-1.9-desktop; KDE/4.7.4; x86_64; ; ) |
Hi Paul,
> Here's a proposed patch to fix a gnulib portability bug uncovered
> with gzip 1.5.
Thanks, the patch is good. Actually when writing this code, I wondered
whether I could use '#define FOO ... defined BAR ...'. Although ISO C 99
6.10.1.(3) explicitly says that it's undefined behaviour:
"If the token defined is generated as a result of this replacement
process or ..., the behavior is undefined."
I tried it and was surprised to see that all compilers support it.
> + Problem reported for gzip by Steven M. Schweda in
> + <http://lists.gnu.org/archive/html/bug-gzip/2012-07/msg00000.html>.
Note the VMS compiler output:
#if !_LIBGETTEXT_HAVE_VARIABLE_SIZE_ARRAYS
.....^
%CC-I-EXPANDEDDEFINED, Macro expansion includes the token "defined", which
will
be treated as an operator. This might not be portable.
1) this is an informational message.
2) it says that the VMS compiler is treating the token 'defined' like all
other compilers do.
> + the C standard says
> + it's not portable to expect that this works after macro expansion.
But real life shows that this construct _is_ portable. It's just that it
makes an assumption that the C standard does not guarantee.
Bruno