[Mesa-dev] [PATCH] xlib: Do not undefine _R, _G, and _B.

[Brian Paul]

On 10/27/2012 11:14 PM, Vinson Lee wrote:
> On Sat, Oct 27, 2012 at 7:15 PM, Kenneth Graunke<kenneth at whitecape.org>  wrote:
>> On 10/27/2012 01:01 PM, Vinson Lee wrote:
>>>
>>> Fixes build error on Cygwin and Solaris. _R, _G, and _B are used in
>>> ctype.h on those platforms.
>>>
>>> Signed-off-by: Vinson Lee<vlee at freedesktop.org>
>>> ---
>>>    src/mesa/drivers/x11/xfonts.c |    3 ---
>>>    1 files changed, 0 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/src/mesa/drivers/x11/xfonts.c b/src/mesa/drivers/x11/xfonts.c
>>> index 9957e89..a92d24a 100644
>>> --- a/src/mesa/drivers/x11/xfonts.c
>>> +++ b/src/mesa/drivers/x11/xfonts.c
>>> @@ -41,9 +41,6 @@
>>>    /* Some debugging info.  */
>>>
>>>    #ifdef DEBUG
>>> -#undef _R
>>> -#undef _G
>>> -#undef _B
>>>    #include<ctype.h>
>>>
>>>    int debug_xfonts = 0;
>>
>>
>> I'm somewhat skeptical that ctype.h actually needs _R, _G, and _B macros
>> defined...and if it does, I'm -really- skeptical that we're #define'ing them
>> to the expected values.  We probably define macros that have a different
>> meaning...
>
>
> I think what is happening is ctype.h is already include indirectly
> through another header. xfonts.c undefines _B. dump_font_struct uses
> the function isprint which is a macro from ctype.h that uses _B. The
> build error occurs because _B was undefined.
>
> Here is the build error.
> src/mesa/drivers/x11/xfonts.c: In function ‘dump_font_struct’:
> src/mesa/drivers/x11/xfonts.c:69:12: error: ‘_B’ undeclared (first use
> in this function)
>
> xfonts.c
>      60  static void
>      61  dump_font_struct(XFontStruct * font)
> [...]
>      68     printf("default_char = %c (\\%03o)\n",
>      69            (char) (isprint(font->default_char) ?
> font->default_char : ' '),
>      70            font->default_char);
>
> ctype.h
>      40  #define _B      0200
> [...]
>      67  #define isprint(__c)    (__ctype_lookup(__c)&(_P|_U|_L|_N|_B))
>
>
> Kenneth, what do you think is the right approach here to fix the build error?

I think the patch is OK as-is.  IIRC, some old Xlib driver code used 
some _R, _G, _B macros in the dithering code (or something like that) 
and this hack worked around the symbol collision.

Reviewed-by: Brian Paul <brianp at vmware.com>

-Brian