[m-users.] Mercury macro trouble

[Volker Wysk]

Hi!

Some quotes from this list:

M. McDonough on 2023-07-19: 
"After some debugging, I now suspect that I know the answer, and it's that
MR_list_cons isn't safe to call directly outside of a foreign_proc because
it can interact with the Mercury register usage."

Peter Wang on 2023-07-20: 
"The problem is that the argument of MR_list_cons(), the call to
CreateNode(), is not evaluated before MR_list_cons() starts doing
anything. You should make the call CreateNode() first, assign the
result to a variable, then perform the MR_list_cons()."

M. McDonough on 2024-04-27: 
"I just want to note this, as it's caused me issues in the past. It's a
bad idea to have anything other than a variable or integral expression
(no function calls, no macros, etc) as the argument to MR_list_cons
(and I would generally say any of the MR_* macros unless you've read
them carefully). You can end up with issues where things are executed
in an unexpected order, and in particular on the low-level C grades,
this can cause big issues with Mercury registers being clobbered
leading to very hard to debug issues with seemingly impossible
behavior."

I think, this is bad and should be addressed.

The obvious solution would be to use inline C functions with the same names
as the macros, instead. Gcc's statement expressions aren't needed.

So I'm asking the Mercury team to scrap all those macros and use inline
functions instead. :-)

No, seriously, I can understand that the Mercury team is reluctant to touch
those long-proven macros.

This leads to the second best solution: Wrap those macros in inline
functions. And instruct the user to use them instead of the macros. For
instance, like this:

static inline MR_Word mr_list_cons(MR_Word head, MR_Word tail)
{
   MR_Word result = MR_list_cons(head, tail);
   return result;
}

This should amend the problem. Or am I missing something? It seems odd to me
that this obvious solution hasn't been implemented already.

Cheers,
Volker