bug-gettext
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-gettext] [PROPOSED] Use VLAs in C11 compilers that advertise th


From: Bruno Haible
Subject: Re: [bug-gettext] [PROPOSED] Use VLAs in C11 compilers that advertise them
Date: Thu, 15 Jun 2017 19:45:51 +0200
User-agent: KMail/5.1.3 (Linux/4.4.0-79-generic; KDE/5.18.0; x86_64; ; )

Hi Paul,

> diff --git a/gnulib-local/lib/gettext.h b/gnulib-local/lib/gettext.h
> index 75f59f6..6316d4d 100644
> --- a/gnulib-local/lib/gettext.h
> +++ b/gnulib-local/lib/gettext.h
> @@ -185,7 +185,7 @@ npgettext_aux (const char *domain,
>  #include <string.h>
>  
>  #if (((__GNUC__ >= 3 || __GNUG__ >= 2) && !defined __STRICT_ANSI__) \
> -     /* || __STDC_VERSION__ >= 199901L */ )
> +     || (201112L <= __STDC_VERSION__ && !defined __STDC_NO_VLA__))
>  # define _LIBGETTEXT_HAVE_VARIABLE_SIZE_ARRAYS 1
>  #else
>  # define _LIBGETTEXT_HAVE_VARIABLE_SIZE_ARRAYS 0

I would leave this as a comment:

   #if (((__GNUC__ >= 3 || __GNUG__ >= 2) && !defined __STRICT_ANSI__) \
        /* || __STDC_VERSION__ == 199901L
           || (__STDC_VERSION__ >= 201112L && !defined __STDC_NO_VLA__) */ )
   # define _LIBGETTEXT_HAVE_VARIABLE_SIZE_ARRAYS 1
   #else
   # define _LIBGETTEXT_HAVE_VARIABLE_SIZE_ARRAYS 0

Why? Around 1992-1997 I learned the lesson that one cannot really rely
on the values of __STDC_VERSION__ and the like. Too many compilers lie
about it. As a consequence, I learned to write autoconf tests for most
things, and be conservative when an autoconf test is not applicable (like
in this case, because gettext.h is installed through "make install").

Has this situation changed meanwhile?

The proposed change has a potential to lead to a bug report for AIX C,
a bug report for Solaris C, a bug report for HP-UX C, a bug report for
PGI C, a bug report for Intel C, and so on. Whereas most people in the
Free Software community care only about GNU C and clang, and for these
compilers _LIBGETTEXT_HAVE_VARIABLE_SIZE_ARRAYS is already 1.

I've learned meanwhile that it is 100 times more important that a package
builds out-of-the-box, rather than that it includes any possible and
thinkable optimization. In this case the risk of build failures is
quite high, compared to a low benefit (avoid malloc calls in rarely used
functions).

Bruno




reply via email to

[Prev in Thread] Current Thread [Next in Thread]