Re: XFree86 4.3.x: ValueUnion and loaded variable names

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

 



On Wed, 18 Feb 2004, Kelledin wrote:

> While compiling XFree86-4.3.0.1 recently, I got the following
> error message:

> In file included from text-mode.c:47:
> loader.h:78: warning: ISO C doesn't support unnamed
> structs/unions              loader.h:78: unnamed fields of type
> other than struct or union are not allowed  text-mode.c: In
> function `TextMode':
> text-mode.c:208: warning: string length `535' is greater than
> the length `509' ISO C89 compilers are required to support
> make[5]: *** [text-mode.o] Error 1
> make[5]: Leaving directory
> `/usr/src/incept/BUILD/xc/programs/Xserver/hw/xfree86/xf86cfg'
> make[4]: *** [all] Error 2
> make[4]: Leaving directory
> `/usr/src/incept/BUILD/xc/programs/Xserver/hw/xfree86'
> make[3]: *** [hw/xfree86] Error 2
> make[3]: Leaving directory
> `/usr/src/incept/BUILD/xc/programs/Xserver'
> make[2]: *** [install] Error 2
> make[2]: Leaving directory `/usr/src/incept/BUILD/xc/programs'
> make[1]: *** [install] Error 2
> make[1]: Leaving directory `/usr/src/incept/BUILD/xc'
> make: *** [install] Error 2

> I looked into it, and it's occurring because of the following
> line in the ValueUnion type:

>     Bool                bool;
>                         ^^^^

> "bool" is a loaded name.  It's a defined type in all C++
> compilers, and it's also defined in plain old non-C++ gcc
> whenever something includes <stdbool.h>.  In my case, I hit it
> for the first time yesterday because <curses.h> from ncurses 5.4
> now includes the <stdbool.h> header.

> So far I see three possible solutions:

> 1) force ncurses to not include <stdbool.h>.  This definitely
> isn't ideal, primarily because it won't stop the next package
> from including <stdbool.h>, and then we'll be dealing with this
> garbage all over again.

> 2) undefine the bool type before defining the ValueUnion type
> (see attached patch).  This is hardly ideal, as several other
> source files in XFree86 depend on that type, and this could give
> us headaches down the road.  Plus, I don't know how portable
> this hack is--it might not work on other toolchains besides
> linux+gcc+libc6.

> 3) rename the ValueUnion.bool field to something else, like xbool
> or boolval.  This would be the perfect solution, except that
> ValueUnion.bool is part of a documented API for XFree86 driver
> modules, and it wouldn't be particularly nice to break the API.
> I would assume there would be ABI breakage as well, since I'm
> not sure exactly how unions get handled at link-time across
> different platforms.

> What I'd probably do is go with (2) for the current 4.3.0 branch,
> and implement (3) for 4.4.0 or some later release where a driver
> API break is marginally acceptable.  Anything besides (3) should
> just be treated as a temporary stopgap measure, as otherwise
> we'd just be digging ourselves deeper into the same hole.

First off, 2) doesn't work if <stdbool.h> is #included after the headers
being modified here.

Secondly (and perhaps more to the point), is that <stdbool.h> is a very
recent (glibc-wise) invention (read: bleeding edge).  So, in your shoes,
I'd first talk to the glibc people about the implications of an stdbool.h
in the first place.

Marc.

+----------------------------------+-----------------------------------+
|  Marc Aurele La France           |  work:   1-780-492-9310           |
|  Computing and Network Services  |  fax:    1-780-492-1729           |
|  352 General Services Building   |  email:  tsi@xxxxxxxxxxx          |
|  University of Alberta           +-----------------------------------+
|  Edmonton, Alberta               |                                   |
|  T6G 2H1                         |     Standard disclaimers apply    |
|  CANADA                          |                                   |
+----------------------------------+-----------------------------------+
XFree86 developer and VP.  ATI driver and X server internals.

_______________________________________________
XFree86 mailing list
XFree86@xxxxxxxxxxx
http://XFree86.Org/mailman/listinfo/xfree86

[Index of Archives]     [X Forum]     [Xorg]     [XFree86 Newbie]     [IETF Announce]     [Security]     [Font Config]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux Kernel]

  Powered by Linux