ImportC and nothrow/@nogc?

[Manu]

On Mon, 26 Aug 2024 at 15:41, Walter Bright via Digitalmars-d <
digitalmars-d at puremagic.com> wrote:

> On 8/24/2024 10:15 AM, Manu wrote:
> > *sigh* ... I'm not going to do that.
> > ImportC either works, or it doesn't... and it currently doesn't work,
> and I'm
> > just going to move on.
> > By far the easiest and least ridiculous feeling thing can do right now
> is to
> > just prototype the occasional C library call inline immediately before
> the call,
> > which is what I've moved on with.
> > Fortunately my call volume is low.
>
> You're right, that will work.
>
> I tried to make C calls default to @trusted. Every single person in the
> community who voiced an opinion on it was dead set against it. But here
> you are,
> saying who cares what C does.
>
> I've got a cannon on one side aimed at me, and a flak gun on the other
> side.
>
> What do you suggest I do?


We're not talking about @trusted, we're talking about nothrow and @nogc...
the community voices that have presented here so far seem to agree; I don't
think you're being pressured by competing opinions.
I *suggest* you make the change, OR consider adding a command line arg to
override it; and optionally make that argument apply to an isolated source
tree if you're feeling particularly conservative. (I wouldn't do that, but
the more conservative might consider it)
The situation as it stands is a literal tragedy... you put a lot of work
into this.

Realistically speaking; C calls are not going to throw or gcalloc. You can
contrive a situation, but you have to go miles out of your way to arrange
that.
Any C library that operates via callbacks will have an API that also has
those attributes attached; in a nothrow @nogc C interface, the user can't
provide a callback that can throw or GC. The only risk vector is as you
described earlier; *mixed use* of the API and using a binary back-door.
The whole point of ImportC, is to use the API.

And if someone does a binary-back-door... who cares? That's called a BUG.
They're playing with fire already! C doesn't have any such type safety, and
they shouldn't expect it to.
They know what they did; they did it intentionally, surely knew what the
risk factors were, and they are naturally expected to not write such bugs
into their program.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20240827/1f7fe178/attachment.htm>