[Top][All Lists]

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

portability checks, errors and warnings

From: Bruno Haible
Subject: portability checks, errors and warnings
Date: Fri, 2 Feb 2007 05:52:43 +0100
User-agent: KMail/1.5.4

Paul Eggert wrote:
> > it can define GNULIB_STRSTR itself:
> >
> >   dnl Tell gnulib that the non-i18n implementation of strstr() is enough
> >   dnl for our purposes.
> This sounds a bit fragile.  mountlist can use a non-i18n
> version of strstr but maybe some mountlist-using apps can't.

Yes, you're right. This looks like a dead end to me too.

> OK, but there are two categories of users here.
> First, maintainers want to detect portability problems.
> Second, installers don't want to be bothered about
> portability problems that do not apply to their platforms.

Yes, this an important observation. Maybe some -DGL_something flag
can distinguish the two cases (see below).

> The current approach caters to maintainers but will cause
> problems for installers.  In the long run this means we'll
> have tarballs leading to installation failures in the field
> that are entirely avoidable.

That's not the case. In string_.h the
  # define stpcpy stpcpy_is_unportable__...
is defined if and only if the module 'stpcpy' is not used in the scope
of the configure.ac. This is a platform independent condition (although
it's config.status which substitutes the @GNULIB_STPCPY@ variable).

Therefore all problems that installers would face from this technique
will be noticeable by the maintainer already.

> Also, to be honest it's getting a bit hard for me to
> follow/understand all this stuff.  I'd like something
> simpler, or at least something more consistent.  When
> maintaining this stuff I get lost about the distinction
> between GNULIB_STRSTR versus REPLACE_STRSTR versus
> HAVE_DECL_STRSTR versus DECL_STRSTR versus 'defined strstr".
> All these identifiers have their roles which make sense
> individually, but the combination is a bit much.

Indeed that deserves some documentation. Here is a beginning:
  - 'defined strstr' tests whether the system has defined 'strstr'
    as a macro.
  - HAVE_STRSTR tests whether the system has defined 'strstr' as a function.
    This is a C macro that is defined to 1 for true, and undefined or
    defined to 0 for false. When used as an AC_SUBSTed variable, it always
    has a value: 1 for true, 0 for false.

Some facilities can be defined either as macros or as functions; this is
why we use

   #if !defined iswspace && !HAVE_ISWSPACE
     /* Here define our own iswspace function. */

  - REPLACE_STRSTR denotes the fact that gnulib provides a replacement
    function for 'strstr'. Often the only portability problem that exists
    is only that a function is missing; then REPLACE_STRSTR = ! HAVE_STRSTR.
    The other case is when the function has bugs on some platforms, and
    gnulib provides a substitute as a workaround against the bugs. In this
    case REPLACE_STRSTR and HAVE_STRSTR may be true simultaneously.

  - HAVE_DECL_STRSTR denotes the fact that the system provide a declaration
    of 'strstr'. Sometimes system don't declare functions that they actually
    have; in this case we use
       #if !HAVE_DECL_STRSTR
         /* Here declare the function strstr.  */
    to provide the missing declaration. Sometimes systems declare functions
    that they don't have, but this is so rare that we normally can assume

  - GNULIB_STRSTR denotes the fact that the gnulib module 'strstr' is in use.
    In this case the programmer can rely on strstr() to be available even
    if ! HAVE_STRSTR - because gnulib provides a substitute if necessary.

> How about something along the following lines instead?  It
> tries to be simpler, or at least more consistent.  This
> would be put in string_.h, for each function that string_.h
> declares.
>   # undef strstr
>   # define strstr @address@hidden
>   #endif
>   extern char *strstr (char const *__haystack, char const *__needle);
>   #endif
>   1 if configure determines that
>     we need to replace the system strlen
>   0 if configure checked the system strlen and found
>     it to be OK.
>   _GL_CHECK_PORTABILITY otherwise.

Hmm, I would much prefer if we could keep the facility for replacement / fixup
of portability problems separate from the facility for detecting the portability
problems. Otherwise setting _GL_CHECK_PORTABILITY may hide portability
problsm - which would defeat its purpose.

>   Maintainers can compile with -D_GL_CHECK_PORTABILITY to
>   enable portability checking.

Yes, I'm thinking in the same direction.

> @RPL_@ is normally rpl_ but could be something else if we
> want to support multiple libraries.

You don't need this. You can use rpl_ always. The 20-line makefile command
that I use in gettext-tools/libgettextpo/Makefile.am solves the problem
of namespace cleanliness.


reply via email to

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