<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 25 Aug 2024 at 21:56, Paolo Invernizzi via Digitalmars-d <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sunday, 25 August 2024 at 11:40:06 UTC, Manu wrote:<br>
> On Sun, 25 Aug 2024 at 21:31, Paolo Invernizzi via <br>
> Digitalmars-d < <a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a>> wrote:<br>
><br>
>> On Sunday, 25 August 2024 at 10:32:31 UTC, Manu wrote:<br>
>> > On Sun, 25 Aug 2024 at 19:56, Paolo Invernizzi via <br>
>> > Digitalmars-d < <a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a>> wrote:<br>
>> ><br>
>> >> On Saturday, 24 August 2024 at 17:43:38 UTC, Manu wrote:<br>
>> >> > On Sun, 25 Aug 2024 at 03:31, Richard (Rikki) Andrew <br>
>> >> > Cattermole via Digitalmars-d <br>
>> >> > <<a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a>> wrote:<br>
>> >> ><br>
>> >> >> On 25/08/2024 5:10 AM, Manu wrote:<br>
>> >> >> > [...]<br>
>> >> >><br>
>> >> >> I've been considering something along these lines.<br>
>> >> >><br>
>> >> >> Specifically, ``@trusted`` does not mean the entire body <br>
>> >> >> shouldn't be verified. It just means that you are going <br>
>> >> >> to do something naughty that needs looking at.<br>
>> >> >><br>
>> >> >> So you need annotated scopes inside of it, to do the <br>
>> >> >> naughty thing.<br>
>> >><br>
>> >> Just wrote a trusted function and call it: that's the sane <br>
>> >> way to do it and respect code reviewer hard job.<br>
>> ><br>
>> ><br>
>> > ...so, because I'm going to make one single unsafe function <br>
>> > call inside of some function, I should eject all other <br>
>> > related or unrelated safety checks for the entire <br>
>> > surrounding context?<br>
>><br>
>> No, you should isolate the unsafe part of code into a <br>
>> function, explain why it’s unsafe, the intent of the code, the <br>
>> expected parameter values and the expected returns, so that <br>
>> reviewer can check that the interface is really memory safe.<br>
>><br>
>> Then call this extremely simple function from the rest of safe <br>
>> code safe code.<br>
>><br>
>><br>
> So, this then:<br>
><br>
> extern(C) int myUnsafeFunction(int x, int y);<br>
><br>
> @trusted int myPointlessWrapper(int x, int y)<br>
> {<br>
>   return  myUnsafeFunction (x, y);<br>
> }<br>
><br>
> @safe mySuperSafeFunction(...)<br>
> {<br>
>    //... lots of code<br>
><br>
>   int r = myPointlessWrapper(arg1, arg2);<br>
><br>
>   //... lots of code<br>
> }<br>
><br>
> Brilliant.<br>
<br>
That’s sidestepping the problem from your side: there’s no <br>
explanation why myUnsafeFunction has an unsafe interface, under <br>
what condition it’s unsafe, and what it’s supposed to do. Neither <br>
any check that it’s parameters are valid and they are not turning <br>
into memory unsafety.<br>
<br>
A reviewer for sure will ask you to add that information and <br>
assurance about memory safety of calling myUnsadeFunction<br>
<br>
If the extern(C) function is intese memory safe, there should be <br>
a way to mark the declaration @safe, also with importC, and there <br>
we can reason about a solution.</blockquote><div><br></div><div>I think you might have missed the point here... we're talking about calling C libraries.</div><div>It already has its interface nicely presented and documented, with expected arguments and returns all written out.</div><div>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.<br></div></div></div>