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

[Zoltan Somogyi]

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.

> > 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.

Renaming variables works, but must be done for each affected predicate,
which is far from ideal. Especially for non-implementors, for whom the problem
will be more baffling than it is for us. So I would prefer a global solution to a
piecemeal solution. I have two approaches that I think would work.

The simpler aka cruder solution would be to add #undefs for all the
potentially colliding #defines at a point *after* all possible (reasonable)
#includes that reach mac.h. Given that foreign_decl pragmas may pull in
mac.h, this would have to be a #undef added by mlds_to_c_file.m
after it prints those pragmas' bodies.

The other solution would be for local_var_name_to_string_for_c to maintain
a database of forbidden variable names. It could then return another name instead.
This name would have to be

- still guaranteed to be different than the names we generate for all other
  vars in the same pred (which could be done by keeping the numeric suffix), and

- it would have to avoid all other forbidden names as well (which would be
  naturally assured if it just so happened that V_N is not forbidden for any N).

There would still be a potential problem if users wrote foreign_procs or foreign_codes
that refer to forbidden names, but there is not much we can do about that,
except document the possible problem.

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.

Zoltan.