[Top][All Lists]
[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
- fcntl for mingw, Eric Blake, 2009/12/10
- Re: fcntl for mingw, Bruno Haible, 2009/12/11
- Re: GL_LINK_WARNING (was: fcntl for mingw),
Bruno Haible <=
- Re: GL_LINK_WARNING, Eric Blake, 2009/12/15
- Re: GL_LINK_WARNING (was: fcntl for mingw), Eric Blake, 2009/12/16
- Re: GL_LINK_WARNING, Eric Blake, 2009/12/16
- Re: GL_LINK_WARNING, Bruno Haible, 2009/12/16
- Re: GL_LINK_WARNING, Eric Blake, 2009/12/16
- Re: GL_LINK_WARNING, Bruno Haible, 2009/12/19
- Re: GL_LINK_WARNING, Jim Meyering, 2009/12/16
- va-args (was: GL_LINK_WARNING), Eric Blake, 2009/12/23