[m-users.] Change in compiler behaviour for 22.01.8 ? Pointer type strictness increased?

[M McDonough]

> On 27 Apr 2024, at 15:30, Volker Wysk <post at volker-wysk.de> wrote:
>
> Am Samstag, dem 27.04.2024 um 11:06 +0200 schrieb Volker Wysk:
>> Hi, Sean
>>
>> Am Samstag, dem 27.04.2024 um 08:42 +0100 schrieb Sean Charles
>> (emacstheviking):
>>> Nope.
>>
>> Really? That's strange. I have this in the improved ODBC library:
>>
>> :- pragma foreign_type("C", statement, "MODBC_Statement *",
>>    [can_pass_as_mercury_type]).
>>
>> And it works.
>>
>> But, this is the type of MR_copy_string:
>>
>>    extern char *MR_copy_string(const char *s);
>>
>> And you have:
>>
>>    Files = MR_list_cons(MR_copy_string(df
l.paths[i]), Files);
>>
>> MR_list_cons is a macro, which I can't see what it does, at the first go.
>> But it seems like it requires an MR_Word as the first argument. Try this:
>>
>>    Files = MR_list_cons((MR_Word) MR_copy_string(dfl.paths[i]), Files);
>>
>> It seems like the C compiler is stricter than in the previous Mercury
>> version, with respect to implicit type conversions. Perhaps someone has
>> added a parameter for the call of gcc. The "-Wint-conversion" from your
>> error messages could be it.
>
> Hmm.. I've looked up -Wint-conversion from the GCC manual, and it says:
>
>    Do not warn about incompatible integer to pointer and pointer to
>    integer conversions.
>
> So it should *not* generate this error. Maybe there's another GCC flag
> that's responsible... I'd just try it with explicit casts.
>
> On the other hand, maybe that mention in your error output is a hint to a
> flag that's *not* being used. Maybe try to add it.
>
> Cheers,
> Volker

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.