Re: irrlamb vs ctype.h

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.