Re: [PATCH v2] gettext.h: add parentheses around N_ expansion if supported

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 8, 2015, 19:10 UTC
Message-ID: <xmqqa91tf5ql.fsf@gitster.dls.corp.google.com>
In-Reply-To: <aea96640a01b65776eb0474aaceded5@74d39fa044aa309eaea14b9f57fe79c>

"Kyle J. McKay" <mackyle@gmail.com> writes:

> For now only __GNUC__ is tested which covers both gcc and clang
> which should result in early detection of any adjacent N_ macros.

I didn't check the list of -W options, but if there were a way to tell gcc to stick to the C standard in a more strict way than its default, wouldn't this patch start causing trouble?

Show 36 quoted lines

> Although the necessary #ifdef makes the header less elegant,
> the benefit of avoiding propagation of a translation-marking
> error to all the translation teams thus creating extra work
> for them when the error is eventually detected and fixed would
> seem to outweigh the minor inelegance the #ifdef introduces.
>
> Signed-off-by: Kyle J. McKay <mackyle@gmail.com>
> ---
>  gettext.h | 14 +++++++++++++-
>  1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/gettext.h b/gettext.h
> index 7671d09d..80ec29b5 100644
> --- a/gettext.h
> +++ b/gettext.h
> @@ -62,7 +62,19 @@ const char *Q_(const char *msgid, const char *plu, unsigned long n)
>  	return ngettext(msgid, plu, n);
>  }
>  
> -/* Mark msgid for translation but do not translate it. */
> +/* Mark msgid for translation but do not translate it.
> + *
> + * In order to prevent accidents where two adjacent N_ macros
> + * are mistakenly used, this macro is defined with parentheses
> + * when the compiler is known to support parenthesized string
> + * literal assignments.  This guarantees a compiler error in
> + * such a case rather than a silent conjoining of the strings
> + * by the preprocessor which results in translation failures.
> + */
> +#ifdef __GNUC__
> +#define N_(msgid) (msgid)
> +#else
>  #define N_(msgid) msgid
> +#endif
>  
>  #endif