ImportC and nothrow/@nogc?

[Manu]

On Thu, 22 Aug 2024 at 05:51, Walter Bright via Digitalmars-d <
digitalmars-d at puremagic.com> wrote:

> On 8/20/2024 2:12 AM, Manu wrote:
> > Exactly... these points are my precise assumption going in here.
> > Also, considering the possibility that D code is called from C code via
> a
> > function pointer; you have to wonder how the C code received a function
> pointer
> > in the first place? If the C code is nothrow @nogc, then it would be
> impossible
> > to supply a function pointer that was not also nothrow @nogc to the C
> code in
> > the first place.
>
> ```
> // D file:
> extern (C) void daFunc() { throw new Exception(); }
> ```
>
> ```
> // C file:
> extern void daFunc();
>
> void hahahahaha() { daFunc(); }
> ```
>
> No function pointers required. The D <=> C interoperability goes both ways.
>
>
That's not a C program, that's a D program with some C code sprinkled in.
But right... a mixture of extern(C) in D code, and also ImportC used in
conjunction, where the ImportC code makes explicit use of symbols that it
expects to find externally...
Feels unlikely, pretty contrived; why would you be using extern(C) if you
are also using ImportC? They're kinda mutually exclusive for my interest. I
wouldn't use ImportC if I was satisfied to write extern(C) bindings.
I mean, being overly cautious like this is not in the spirit of using C
code at all! C code will _always_ introduce these sorts of risks 100%
without question. If you're stressed about this, while also having no
agency to control your environment or test your programs validity, you
kinda have no business linking to C code in the first place.

But all that as it is, so... we add a compiler flag to control whether
these 2 attributes are applied to ImportC declarations or not?

The current situation is not reasonable. You've done all this work and made
all this hype, the first time I want to make use of it, it turns out it's
not actually usable by the exact sort of code that seems the most likely to
want to use the feature in the first place!
C doesn't throw or GC, period. Of course I can contort a C environment to
do whatever I want; but the argument that C can throw or can GC alloc
implies that the C code is not actually C code... it is infact actually
just a small piece of connective tissue in some non-C project.
A C library that is a self-contained package does not call C++ code or D
code. We need a way to assert this case. I think a compile option which
asserts this case seems fine.
Maybe apply the arg to a directory; in the event there are multiple C
libraries being included in the project, it only applies to C code under
that path, like some self-contained libraries?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20240822/e9e5126d/attachment.htm>