ImportC and nothrow/@nogc?

[Paolo Invernizzi]

On Sunday, 25 August 2024 at 16:58:53 UTC, Manu wrote:
> On Sun, 25 Aug 2024 at 23:25, Paolo Invernizzi via 
> Digitalmars-d < digitalmars-d at puremagic.com> wrote:
>
>> On Sunday, 25 August 2024 at 12:47:13 UTC, Manu wrote:
>> > On Sun, 25 Aug 2024 at 21:56, Paolo Invernizzi via 
>> > Digitalmars-d < digitalmars-d at puremagic.com> wrote:
>> >
>> >> On Sunday, 25 August 2024 at 11:40:06 UTC, Manu wrote:
>> >> > [...]
>> >>
>> >> That’s sidestepping the problem from your side: there’s no
>> >> explanation why myUnsafeFunction has an unsafe interface, 
>> >> under
>> >> what condition it’s unsafe, and what it’s supposed to do.
>> >> Neither
>> >> any check that it’s parameters are valid and they are not
>> >> turning
>> >> into memory unsafety.
>> >>
>> >> A reviewer for sure will ask you to add that information 
>> >> and assurance about memory safety of calling 
>> >> myUnsadeFunction
>> >>
>> >> If the extern(C) function is intese memory safe, there 
>> >> should be a way to mark the declaration @safe, also with 
>> >> importC, and there we can reason about a solution.
>> >
>> >
>> > I think you might have missed the point here... we're talking
>> > about calling
>> > C libraries.
>> > It already has its interface nicely presented and documented,
>> > with expected
>> > arguments and returns all written out.
>> > We just want to call a function, that's all. There's no 
>> > safety
>> > 'risk' here
>> > to comment on, unless you consider using a C library to be a
>> > risk in
>> > principle.
>>
>> Using a C library IS a risk in principle, if it includes memory
>> unsafe function interfaces.
>> The memory unsafe C interface (@system) must be called from a
>> @trusted function that ensure that proper parameters and
>> conditions are properly set to not trigger memory unsafely:
>> that's basically the whole point of @trusted.
>>
>
> Right, but in ~95% of cases C functions don't have anything 
> about them that makes them memory unsafe, or any relevant 
> validation or concerning API material... they're just de-facto 
> unsafe.
>
> Here's some great functions that I plucked from top of my head:
>
> float abs(float);
> int rand();
> void sleep(int);
> int fclose(FILE);
> pid_t getpid();
>
> It's obviously stupid to write a wrapper function for every 
> single C
> function we use. That's entirely self-defeating.
> Why would anybody import a C header file if they have to write 
> as many
> function wrappers as C function prototypes imported? Might as 
> well have
> just written the prototypes... it's actually LESS code.

If you know that 100% of the C function prototypes you are 
importing are memory safe, then yes, that's yes, having them 
imported as @system is an annoyance, and DLang can be improved 
with some way to pragma the compiler to importC the file as @safe

On the other side, if you know that you have 95% of memory safety 
C functions, and 5% of memory unsafe function, marking that 5% as 
@trusted or @safe is just safe-washing, it's not acceptable in a 
code base that aims to be serious about memory safety.

> And then there's maybe kinda contentious ones, like:
>
> FILE fopen(char* filename, char* mode);
>
> Now, clearly there's a null-termination concern here, but 
> that's not actually a category of issue that @safe is concerned 
> with as far as I know. Generally, the user just wants to do 
> this:
>
> unsafe {
>   FILE f = fopen(filename.toStringz, "rb");
> }
>
> There's no value in writing a whole function wrapper to 
> automate a call to
> toStringz().
> I'm not even sure that call is actually unsafe anyway. 
> toStringz() isn't
> unsafe...?

Indeed we do that all the time, to provide some kind of D-way to 
call C-API. As you see, the inconvenience mark it's just a matter 
of taste, an opinion.

> I further agree with you that would be good to have a clever way
>> to declare @safe declarations for SOME function automatically 
>> declared by importC.
>>
>
> That list I wrote above and a million functions of that nature; 
> they don't
> have any interaction with @safe... declaring them @system is 
> nothing more
> than a nuisance. Nothing is added by not trusting them.
> If there's some API tell-tales that can definitively determine 
> the safety
> of a function, then maybe it could make an educated guess... 
> but failing
> that, then there's a serious practical conundrum here.

The point here is that's not something like 'maybe my process is 
memory safe, by educated guess', it's not a matter of being 
practical or not. If memory safeties is a value, than it should 
be threaded seriously also if it involves not practical way of 
ensuring it.

Any addition to alleviate the burden is welcomed, especially for 
import C, but without throwing the @safety baby with the water.