[m-rev.] diff: Avoid SC_32 name collision in generated C code.

[Peter Wang]

On Wed, 30 Apr 2025 15:37:34 +1000 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> 
> 
> On Wed, 30 Apr 2025 14:23:28 +1000, Peter Wang <novalazy at gmail.com> wrote:
> 
> > On Wed, 30 Apr 2025 13:14:05 +1000 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> > > 
> > > 
> > > On Wed, 30 Apr 2025 11:54:04 +1000, Peter Wang <novalazy at gmail.com> wrote:
> > > > On AIX, /usr/include/sys/mac.h contains the macros:
> > > > 
> > > >     #define SC_32 32
> > > >     #define SM_32 8
> > > 
> > > What is the job of that header file? Surely not supporting AIX on Apple Macs.
> > 
> > Something about "security labels".
> 
> Ah. That would have been my second guess: MAC = Mandatory Access Control.
> 

No, it's not that either.

> > > A grep for mac.h in a workspace
> > > returned no matches, not even in test_bitset.m. What causes the
> > > above macros to be visible in test_bitset.c?
> > 
> > It turns out including <pthread.h> pulls it in indirectly.
> 
> OK, that is something that we cannot easily avoid, so we must handle it.

I wouldn't say that. It's an unlikely name clash on a niche platform.

I'm likely the only one who has dealt with Mercury on AIX in the last
decade or more. We just have one customer that occasionally requests a
build of Prince for AIX. For unrelated reasons, we haven't even been
able to provide one since 2019. I'm only investigating if it's possible
again now. I expect we won't be dealing with AIX much longer.

If you want, we can #undef the macros after including <pthread.h> in
mercury_thread.h. That's as much thought as I'd put into it.

> The second approach is somewhat costlier in terms of compile time, but it does
> allow e.g. SC_32 to be used as pthread.h intends by foreign_code pragmas,
> which the first approach does not allow.

SC_32 has nothing to do with the pthreads API. It's just happens to be
included indirectly.

Peter