Re: irrlamb vs ctype.h

2023-12-28T19:21:30Z Theo Buehler <tb@theobuehler.org>:

> On Thu, Dec 28, 2023 at 06:48:52PM +0000, Johannes Thyssen Tishman wrote:
>> 2023-12-28T17:58:12Z Theo Buehler <tb@theobuehler.org>:
>>
>>> I could use a set of eyes on this for the case that I'm missing something.
>>>
>>> Newer libcxx pulls in ctype.h which defines _L and _C to flag values, that
>>> doesn't work well with the existing code. This results in this kind of error:
>>>
>>> c++: warning: argument unused during compilation: '-s' [-Wunused-command-line-argument]
>>> /tmp/pobj/irrlamb-1.0.1/irrlamb-1.0.1r613/src/ode/src/lcp.cpp:382:33: error: expected ')'
>>>         dReal *_pairslh, dReal *_L, dReal *_d,
>>>                                 ^
>>> /usr/include/ctype.h:46:12: note: expanded from macro '_L'
>>> #define _L      0x02
>>>                 ^
>
>> Slightly unrelated, but I'm having a similar issue with a OrocosKDL[1]
>> port I'm working on (port not attached as I'm using the phone, sorry).
>> I opened an issue[2] where I posted the log of a build with GCC where
>> you can see similar errors. Compiling with base clang returned the
>> same "error: expected ')'" errors though.
>
> It is the same problem and it is seen in ports occasionally.
>
> /usr/include/ctype.h has this:
>
> #define _U  0x01
> #define _L  0x02
> ...
> https://github.com/openbsd/src/blob/master/include/ctype.h#L45-L52
>
> To my understanding it's an old BSDism and it's used to implement
> isupper(3), islower(3), etc. Someone pointed out to me that FreeBSD and
> NetBSD switched to using _CTYPE_U, etc decades age. This is much less
> likely to cause problems with ports.
>
> If you include ctype.h and use _U, _L, ... as variable name, you run
> into this.  To spell it out completely:
>
> $ cat name.c
> #include <ctype.h>
>
> int
> main(void)
> {
>     int _L = 25;
>     return _L;
> }
> $ cc name.c
> name.c:6:6: error: expected identifier or '('
>         int _L = 25;
>             ^
> /usr/include/ctype.h:46:12: note: expanded from macro '_L'
> #define _L      0x02
>                 ^
> 1 error generated.
>
> Here's what the preprocessor does:
>
> $ cc -E name.c | tail -n 7
> # 2 "name.c" 2
>
> int
> main(void)
> {
> int 0x02 = 25;
>         return 0x02;
> }
>
> That won't work... Commenting out the #include (usually not an option
> in non-toy code) or renaming the variable makes it work.

Thanks for the explanation and the example. I understand what's going on now. I will test renaming the relevant variables in my port and suggest the changes upstream.