String params on some methods

[Gounlaf]

👋

I'm not used to c/c++ ; so I don't know the implications of some things...

I found an explanation for const char*, const char*, char* const and const char* const here https://stackoverflow.com/a/9834194/2098861 ( 🤯 ).

const char* are translated as String directly by Kotlin C Interop.

As a result, I can pass directly a String to MagickImage_SetAttribute ; from a developer pov, it's... fantastic 😍🤩

But signature of MagickImage_Annotate is slightly different ; from a developer pov, it's "less fantastic" ; it's not a big deal because Kotlin provide lot of extensions functions 🤩

From Magick.NET perspective, I see no difference at all (I may be wrong) ; it seems you always provide a pointer to the String directly (with UTF8Marshaler).

From ImageMagick perspective, I don't understand why, sometimes, the strings could be mutable.
From Magick.Native perspective, I understand that the exact API of ImageMagick is followed.

Could Magick.Native sanitize or "fix" some ImageMagick APIs?

Like I said, I don't understand why the strings could be mutable ; and like I said, I'm not used to c/c++ 😅

Any enlightenment is welcome.

Thanks!

Regards.

[dlemstra]

The arguments for MagickImage_Annotate are char * because the drawInfo needs a char *. This is done because it wants to cleanup the text and geometry/boundingArea. But I am already preventing ImageMagick from doing that because I need to free the memory on the C# side. I could change those arguments into const char * for the Native library and do the typecast inside the MagickImage_Annotate method if that would help you.

[Gounlaf]

The arguments for MagickImage_Annotate are char * because the drawInfo needs a char *.

I was meaning that with "I understand that the exact API of ImageMagick is followed." 😅

I could change those arguments into const char * for the Native library and do the typecast inside the MagickImage_Annotate method if that would help you.

Since Magick.Native is kind of a bridge, it would make more sens imho to do it everywhere, having a "unified" API / behavior.

I don't really understand the deep consequences of that kind of changes.

Like I said, it not really a blocking issue. I'm just trying to understand how it works 🙂

[dlemstra]

It's no effort to change this api so I just pushed a patch to make this easier for you.

[Gounlaf]

Thanks!