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

[Sean Charles (emacstheviking)]

Thanks Volker for shining the torch into the darkness!

It's all working now, the code changed from:


:- pragma foreign_type("C", rsound,   "MR_Integer*", [can_pass_as_mercury_type]).
:- pragma foreign_type("C", rmusic,   "MR_Integer", [can_pass_as_mercury_type]).
:- pragma foreign_type("C", rfont,    "MR_Integer", [can_pass_as_mercury_type]).
:- pragma foreign_type("C", rtexture, "MR_Integer", [can_pass_as_mercury_type]).
:- pragma foreign_type("C", rshader,  "MR_Integer", [can_pass_as_mercury_type]).

to:

:- pragma foreign_type("C", rsound,   "Sound*", [can_pass_as_mercury_type]).
:- pragma foreign_type("C", rmusic,   "Music*", [can_pass_as_mercury_type]).
:- pragma foreign_type("C", rfont,    "Font*", [can_pass_as_mercury_type]).
:- pragma foreign_type("C", rtexture, "Texture2D*", [can_pass_as_mercury_type]).
:- pragma foreign_type("C", rshader,  "Sh*", [can_pass_as_mercury_type]).


And... turns out I was lucky, because somehow I had mis-read / misunderstood the documentation, as I often do!, and somehow was under the impression that the third parameter to foreign_type HAD to be a Mercury type, hence my crazy question. It was your use of MODBC_Statement that made the -penny drop! I could blame the chemotherapy (why Ive not posted much lately) but mostly I really am this stupid., :D


So, once again, thank you Volker.
My video game compiles and runs again, and I learned something.


> 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(dfl.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
> 
> 
> _______________________________________________
> users mailing list
> users at lists.mercurylang.org <mailto:users at lists.mercurylang.org>
> https://lists.mercurylang.org/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/users/attachments/20240427/7bb62be9/attachment-0001.html>