[Libevent-users] Re: Bug#632490: libevent-dev: namespace polution (#define-s _GNU_SOURCE)

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

On Sat, Jul 2, 2011 at 3:33 PM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote:
> Package: libevent-dev
> Version: 2.0.12-stable-1
> Severity: important
> Justification: beanstalkd ftbfs
> Files: /usr/include/event2/util.h
>
> Hi,
>
> Trying to build beanstalkd, I get:
>
> | gcc -DHAVE_CONFIG_H -I.     -g -O2  -Wall -Werror -I/usr/include -c -o tube.o tube.c
> | In file included from /usr/include/event2/event.h:48:0,
> |                  from /usr/include/event.h:192,
> |                  from conn.h:23,
> |                  from prot.h:22,
> |                  from tube.c:25:
> | /usr/include/stdio.h:417:12: error: expected identifier or ‘(’ before ‘void’
> | /usr/include/stdio.h:417:12: error: expected ‘)’ before numeric constant
> | make[2]: *** [tube.o] Error 1
>
> That line in stdio.h defines dprintf(), which is used by beanstalkd
> for a totally unrelated purpose (#define dprintf(x) (void) 0).  So far
> that had not been a problem because until POSIX.1-2008, dprintf was in
> the application namespace and POSIX implementations were not allowed to
> step on that.
>
> Indeed, glibc does not define dprintf unless someone has requested
>
>        #define _XOPEN_SOURCE 700
>
> or "#define _GNU_SOURCE" or similar (see feature_test_macros(7)).
> Unfortunately libevent's util.h defines _GNU_SOURCE, meaning
> applications using it have no reliable guarantees about what function
> names are available for their own use.
>
> Also relevant is that POSIX only guarantees that defining feature test
> macros will work if it's done before the very first #include of a
> system header.  So ideally this would be the application's
> responsibility.
>
> Luckily util.h already has ifdefs to gracefully cope even with systems
> without any netdb.h at all.

Unfortunately, it's not so graceful at all: the #ifdefs define
constants and structures based on the values and layouts associated
with the getaddrinfo() interface.  (At least, if I recall correctly,
that's what Libevent is up to here.)  In other words, the libevent
EAI_X values are the same as the system EAI values... but if the
header sometimes defines its own values (when the user hasn't set
GNU_SOURCE) and sometimes doesn't, there will be a mismatch between
the system values and Libevent's values, and code that doesn't define
the right options will break.

We could say, "Libevent should always use its own evutil_addrinfo, and
its own EVUTIL_EAI codes".  That would break ABI compatibility,
though, and I'd rather wait for 2.1 to do that.

>  I think the best thing to do would be to
> allow the application to define _GNU_SOURCE and take advantage of the
> additional error numbers opportunistically, or maybe even something
> like
>
>        #ifndef _GNU_SOURCE
>        #warning "please define _GNU_SOURCE for full functionality"
>        #endif
>
> There is arguably also a bug in beanstalkd here --- friendly programs
> do not rely on outdated versions of POSIX.  But that's a less
> important bug, so let's deal with this one first. :)

I'd definitely like help working on and testing a patch for Libevent
to fix this. It's not something I can comfortably put into mainline
Libevent the  2.0 (stable) series because of the ABI-breaking issue
and because of the possibility of breaking other code, but I'd love to
see it fixed in 2.1.

> Thanks for reading, and hope that helps.
>
> Regards,
> Jonathan
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.