Re: [XFree86] XFree86 4.3.x: ValueUnion and loaded variable names
On Fri, 20 Feb 2004, Thomas Dickey wrote: > > >This thread actually started on [EMAIL PROTECTED] The problem is that gcc's > > >broken define conflicts with our driver API. > > ISO C99: > > 7.16 > > Boolean type and values > > 1 The header defines four macros. > > 2 The macro bool expands to _Bool. > > Which define is broken in gcc exactly? OK. So "broken" is a little harsh. Not the first time... > recap: one of his header files has a struct with a field named 'bool'. > ncurses' curses.h is including stdbool.h (long story). > stdbool.h's bool definition interferes with his header file. Well, not "his" header file, exactly, but I'll let that go. The simplest thing to do is to rename that field in xf86cfg/loader.h. As for the field in common/xf86Opt.h, that header is only used by server code, and server code shouldn't ever use curses. That leaves some future #include in server code, but we can cross that bridge when/if we get there. In the meantime, the API issue is avoided. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] XFree86 4.3.x: ValueUnion and loaded variable names
On Fri, 20 Feb 2004, Mike A. Harris wrote: > On Fri, 20 Feb 2004, Marc Aurele La France wrote: > > >This thread actually started on [EMAIL PROTECTED] The problem is that gcc's > >broken define conflicts with our driver API. > > ISO C99: > > 7.16 > > Boolean type and values > > 1 The header defines four macros. > 2 The macro bool expands to _Bool. > > > > Which define is broken in gcc exactly? recap: one of his header files has a struct with a field named 'bool'. ncurses' curses.h is including stdbool.h (long story). stdbool.h's bool definition interferes with his header file. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] XFree86 4.3.x: ValueUnion and loaded variable names
On Fri, 20 Feb 2004, Marc Aurele La France wrote: >This thread actually started on [EMAIL PROTECTED] The problem is that gcc's >broken define conflicts with our driver API. ISO C99: 7.16 Boolean type and values 1 The header defines four macros. 2 The macro bool expands to _Bool. Which define is broken in gcc exactly? -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] XFree86 4.3.x: ValueUnion and loaded variable names
On Fri, 20 Feb 2004, Kelledin wrote: > >> I don't see the original comment on the mail archive - but have the > >> impression that he's trying to use some definition that relies on the > >> bogus "bool" from stdbool.h - So I guess the best recommendation is that > >> he should update to the regular release version of ncurses rather than > >> one > >> of the development versions. > > > > Thanks for responding. > > > > This thread actually started on [EMAIL PROTECTED] The problem is that gcc's > > broken define conflicts with our driver API. > > Well, that's rather debatable. From what I can gather on Google, C99 7.16 > actually allows for stdbool.h and the relevant macros for bool, true, and > false. Of course, it breaks ANSI C89/C90, but as the gcc devs point out, > ANSI C89/C90 code shouldn't be including stdbool.h in the first place. hmm - checking (I do have a copy of C99), you're correct. I only recalled _Bool (and also some comments from google that indicated the original reason for adding the macro had to do with C++), but see that C99 states that "The macro bool expands to _Bool". On the second part - maybe not. The wide-character code is not C89, but uses features from 1996/1998. But iirc, the reason why it's including stdbool.h is to try to iron out whatever problems arise from applications that might include it. > Unfortunately, I don't have a copy of C99 (and can't afford to purchase it > atm), so I'm in no position to argue the finer points. $20US for a PDF > Furthermore, if we applied this "fix", then curses.h would break whenever > it got run through gcc -ansi. > > Perhaps the best solution here is for curses.h to simply not have anything > to do with stdbool.h? (and, of course, put the #undef bool at the end, as > it was in 5.3) perhaps - but (not inclined to argue at this point) will have to research it a little more. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] XFree86 4.3.x: ValueUnion and loaded variable names
Marc Aurele La France said: > On Fri, 20 Feb 2004, Thomas Dickey wrote: >> On Fri, 20 Feb 2004, Marc Aurele La France wrote: >> > Anyway, some versions of ncurses #undef bool just after #include'ing >> > . Thomas Dickey, ncurses developer, is on this list, so if >> > he's reading this, he probably has some suggestions. > >> I overlooked the beginning of the thread. stdbool.h is a C99 file, >> which >> is fine. But defining "bool" in that file is a gcc-ism. Both gcc's >> stdbool.h and ncurses.h are trying to solve the same problem (though >> ncurses.h has a more valid reason - "bool" is a documented part of >> X/Open >> curses, gcc is doing it solely as an extension). > >> In current ncurses (5.4), I don't have an undef for bool following >> stdbool.h -- there was an undef in the version from last spring. That >> was >> to work around (no surprise) a conflict on BeOS with inconsistent >> definitions of bool. If gcc hadn't added that definition to stdbool.h >> the >> #undef wouldn't have been needed. > >> I don't see the original comment on the mail archive - but have the >> impression that he's trying to use some definition that relies on the >> bogus "bool" from stdbool.h - So I guess the best recommendation is that >> he should update to the regular release version of ncurses rather than >> one >> of the development versions. > > Thanks for responding. > > This thread actually started on [EMAIL PROTECTED] The problem is that gcc's > broken define conflicts with our driver API. Well, that's rather debatable. From what I can gather on Google, C99 7.16 actually allows for stdbool.h and the relevant macros for bool, true, and false. Of course, it breaks ANSI C89/C90, but as the gcc devs point out, ANSI C89/C90 code shouldn't be including stdbool.h in the first place. Unfortunately, I don't have a copy of C99 (and can't afford to purchase it atm), so I'm in no position to argue the finer points. Furthermore, if we applied this "fix", then curses.h would break whenever it got run through gcc -ansi. Perhaps the best solution here is for curses.h to simply not have anything to do with stdbool.h? (and, of course, put the #undef bool at the end, as it was in 5.3) -- Kelledin "If a server crashes in a server farm and no one pings it, does it still cost four figures to fix?" ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] XFree86 4.3.x: ValueUnion and loaded variable names
On Fri, 20 Feb 2004, Thomas Dickey wrote: > On Fri, 20 Feb 2004, Marc Aurele La France wrote: > > Anyway, some versions of ncurses #undef bool just after #include'ing > > . Thomas Dickey, ncurses developer, is on this list, so if > > he's reading this, he probably has some suggestions. > I overlooked the beginning of the thread. stdbool.h is a C99 file, which > is fine. But defining "bool" in that file is a gcc-ism. Both gcc's > stdbool.h and ncurses.h are trying to solve the same problem (though > ncurses.h has a more valid reason - "bool" is a documented part of X/Open > curses, gcc is doing it solely as an extension). > In current ncurses (5.4), I don't have an undef for bool following > stdbool.h -- there was an undef in the version from last spring. That was > to work around (no surprise) a conflict on BeOS with inconsistent > definitions of bool. If gcc hadn't added that definition to stdbool.h the > #undef wouldn't have been needed. > I don't see the original comment on the mail archive - but have the > impression that he's trying to use some definition that relies on the > bogus "bool" from stdbool.h - So I guess the best recommendation is that > he should update to the regular release version of ncurses rather than one > of the development versions. Thanks for responding. This thread actually started on [EMAIL PROTECTED] The problem is that gcc's broken define conflicts with our driver API. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] XFree86 4.3.x: ValueUnion and loaded variable names
On Fri, 20 Feb 2004, Kelledin wrote: > Thomas Dickey said: > > I don't see the original comment on the mail archive - but have the > > impression that he's trying to use some definition that relies on the > > bogus "bool" from stdbool.h - So I guess the best recommendation is that > > he should update to the regular release version of ncurses rather than one > > of the development versions. > > Well, just to bring everyone up to speed...the problem we face is that > XFree86 defines a union type called ValueUnion, and names one of the union > fields "bool". Obviously this wasn't really a great idea. It bites us > now because ncurses 5.4 includes , which defines the bool type, > which confuses the hell out of gcc when it hits the ValueUnion typedef. :( ok (at least we're current). > The simple answer would be to change the ValueUnion field name to "xbool" > or the like. The problem is, this naming snafu has become part of a > publicly documented API for XFree86 driver development. "bool" is a keyword in C++, and is a bad choice for a variable name (even if the compiler can keep it distinct). > IMO modifying ncurses would only be a temporary fix, good only until the > next system header decides it needs . > > BTW--"regular version" of ncurses? Is 5.4 a stable release or not? FWIW > I pulled it off ftp.gnu.org...if it's "unstable", it ought to be taken > down from there and put on alpha.gnu.org. no. I was referring obliquely to various packagers' pulling patches from my development area and releasing them (ftp://invisible-island.net/ncurses/). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] XFree86 4.3.x: ValueUnion and loaded variable names
Thomas Dickey said: > I don't see the original comment on the mail archive - but have the > impression that he's trying to use some definition that relies on the > bogus "bool" from stdbool.h - So I guess the best recommendation is that > he should update to the regular release version of ncurses rather than one > of the development versions. Well, just to bring everyone up to speed...the problem we face is that XFree86 defines a union type called ValueUnion, and names one of the union fields "bool". Obviously this wasn't really a great idea. It bites us now because ncurses 5.4 includes , which defines the bool type, which confuses the hell out of gcc when it hits the ValueUnion typedef. :( The simple answer would be to change the ValueUnion field name to "xbool" or the like. The problem is, this naming snafu has become part of a publicly documented API for XFree86 driver development. IMO modifying ncurses would only be a temporary fix, good only until the next system header decides it needs . BTW--"regular version" of ncurses? Is 5.4 a stable release or not? FWIW I pulled it off ftp.gnu.org...if it's "unstable", it ought to be taken down from there and put on alpha.gnu.org. -- Kelledin "If a server crashes in a server farm and no one pings it, does it still cost four figures to fix?" ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] XFree86 4.3.x: ValueUnion and loaded variable names
On Fri, 20 Feb 2004, Marc Aurele La France wrote: > Redirected from xfree86@ to devel@, where this belongs. > > On Thu, 19 Feb 2004, Kelledin wrote: > > On Thursday 19 February 2004 03:42 pm, Marc Aurele La France wrote: > > > Secondly (and perhaps more to the point), is that > > > 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. > > > Not that bleeding edge. stdbool.h is part of gcc and has been > > around since stock 2.95.3 (possibly earlier as well). 2.95.3 > > is...downright ancient, at least in software terms. > > Ooops, right. I was only looking at /usr/include. > > Anyway, some versions of ncurses #undef bool just after #include'ing > . Thomas Dickey, ncurses developer, is on this list, so if > he's reading this, he probably has some suggestions. I overlooked the beginning of the thread. stdbool.h is a C99 file, which is fine. But defining "bool" in that file is a gcc-ism. Both gcc's stdbool.h and ncurses.h are trying to solve the same problem (though ncurses.h has a more valid reason - "bool" is a documented part of X/Open curses, gcc is doing it solely as an extension). In current ncurses (5.4), I don't have an undef for bool following stdbool.h -- there was an undef in the version from last spring. That was to work around (no surprise) a conflict on BeOS with inconsistent definitions of bool. If gcc hadn't added that definition to stdbool.h the #undef wouldn't have been needed. I don't see the original comment on the mail archive - but have the impression that he's trying to use some definition that relies on the bogus "bool" from stdbool.h - So I guess the best recommendation is that he should update to the regular release version of ncurses rather than one of the development versions. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] XFree86 4.3.x: ValueUnion and loaded variable names
Redirected from xfree86@ to devel@, where this belongs. On Thu, 19 Feb 2004, Kelledin wrote: > On Thursday 19 February 2004 03:42 pm, Marc Aurele La France wrote: > > Secondly (and perhaps more to the point), is that > > 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. > Not that bleeding edge. stdbool.h is part of gcc and has been > around since stock 2.95.3 (possibly earlier as well). 2.95.3 > is...downright ancient, at least in software terms. Ooops, right. I was only looking at /usr/include. Anyway, some versions of ncurses #undef bool just after #include'ing . Thomas Dickey, ncurses developer, is on this list, so if he's reading this, he probably has some suggestions. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
