bug-gnulib
[Top][All Lists]
Advanced

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

Re: GL_LINK_WARNING (was: fcntl for mingw)


From: Bruno Haible
Subject: Re: GL_LINK_WARNING (was: fcntl for mingw)
Date: Wed, 16 Dec 2009 00:51:48 +0100
User-agent: KMail/1.9.9

Hi Eric,

> > 2. Ditch this series, and instead go and change all uses of 
> > GNULIB_POSIXCHECK 
> > that used
> >  #define func(args) (GL_LINK_WARNING("..."),func(args))
> > to instead use
> >  #define func (GL_LINK_WARNING("..."),func)

You would need that only for functions that take a variable number of arguments.
Currently
  - openat, fprintf, printf, snprintf, fprintf are already using your proposed
    idiom,
  - ioctl is not, and should be changed.

But I would not change _all_ uses of GNULIB_POSIXCHECK in this way, because
it would increase the probability of a collision. If a user uses a variable
or field named 'func', then in most cases it does not collide with an earlier
macro definition
   #define func(args) (GL_LINK_WARNING("..."),func(args))
but it would give a syntax error with a macro definition
   #define func (GL_LINK_WARNING("..."),func)

> gcc provides a more generic solution that will also work for Cygwin and
> other non-ELF platforms? 
> ...
> char * __attribute__((__cdecl__)) mktemp (char *) __attribute__ ((warning 
> ("the use of `mktemp' is dangerous; use `mkstemp' instead")));

Great! This attribute is supported since GCC 4.3.0, that is, since 2008.
So, many current distros support it already.

I prefer this macro to our old GL_LINK_WARNING for four reasons:
  1) Provides a warning immediately at compile-time. The user does not have
     to wait until he links a program.
  2) Less use of C macros. Less risk of collision.
  3) It's available on more platforms. Depends only on GCC.
  4) The formatting of the message is nicer.

You can even suggest this warning as an addition to glibc's libc-symbols.h.

There is one trick needed, though. Suppose the system has a function which may
be declared as
    int foo (void *p);
or  int foo (char *p);
How can we add the attribute?
  - If we write
      extern int foo (void *p) __attribute__ ((__warning__ ("message")));
    we get a compiler error in the second case (in C mode).
  - If we write
      extern int foo (char *p) __attribute__ ((__warning__ ("message")));
    we get a compiler error in the first case (in C mode).
  - If we write
      extern int foo () __attribute__ ((__warning__ ("message")));
    we get no effect in C++ mode.
  - The trick is to write
      #if HAVE_DECL_FOO
      extern __typeof__(foo) foo __attribute__ ((__warning__ ("message")));
      #endif

> 4. Redefine GL_LINK_WARNING to instead be a way to apply __attribute__
> ((__warning__)) as a function attribute when gcc supports it (and probably 
> rename the module/macro from link-warning/GL_LINK_WARNING to usage-
> warning/GL_USAGE_WARNING, since it would now be a compiler rather than a 
> linker 
> warning), and adjust all GNULIB_POSIXCHECK call points to use the new 
> semantics.

I like it. You can leave the old 'link-warning' module as it is; some other
package may be using it. Just create a new module 'usage-warning' or
'use-warning'.

About the name: GL_USAGE_WARNING? GL_USE_WARNING? I'm not an English speaker,
but "usage" reminds me the --help explanations of every program.

About the prefix: As discussed a couple of days ago, with arg-nonnull.h, better
use the prefix _GL_ than GL_.

Bruno




reply via email to

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