<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 25 Aug 2024 at 23:25, 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 12:47:13 UTC, Manu wrote:<br>
> On Sun, 25 Aug 2024 at 21: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 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 <br>
>> >> >> >> body<br>
>> >> >> >> shouldn't be verified. It just means that you are <br>
>> >> >> >> 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 <br>
>> >> >> sane way to do it and respect code reviewer hard job.<br>
>> >> ><br>
>> >> ><br>
>> >> > ...so, because I'm going to make one single unsafe <br>
>> >> > function call inside of some function, I should eject all <br>
>> >> > other 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, <br>
>> >> 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 <br>
>> >> safe 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. <br>
>> Neither<br>
>> any check that it’s parameters are valid and they are not <br>
>> 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 <br>
>> be a way to mark the declaration @safe, also with importC, and <br>
>> there we can reason about a solution.<br>
><br>
><br>
> I think you might have missed the point here... we're talking <br>
> about calling<br>
> C libraries.<br>
> It already has its interface nicely presented and documented, <br>
> with expected<br>
> arguments and returns all written out.<br>
> We just want to call a function, that's all. There's no safety <br>
> 'risk' here<br>
> to comment on, unless you consider using a C library to be a <br>
> risk in<br>
> principle.<br>
<br>
Using a C library IS a risk in principle, if it includes memory <br>
unsafe function interfaces.<br>
The memory unsafe C interface (@system) must be called from a <br>
@trusted function that ensure that proper parameters and <br>
conditions are properly set to not trigger memory unsafely: <br>
that's basically the whole point of @trusted.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>Here's some great functions that I plucked from top of my head:</div><div><br></div><div>
<div>float abs(float);</div><div>int rand();</div><div>
<div>void sleep(int);<br></div><div>
<div>
<span class="gmail-hljs-type"></span></div></div>
int fclose(FILE);</div><div>
<div>
<span class="gmail-hljs-type">pid_t</span> getpid(); <br></div><div></div>
</div>
</div><div><br></div><div>It's obviously stupid to write a wrapper function for every single C function we use. That's entirely self-defeating.<br></div><div>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.<br></div><div><br></div><div>And then there's maybe kinda contentious ones, like:</div><div><br></div><div>FILE fopen(char* filename, char* mode);</div><div><br></div><div>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.</div><div>Generally, the user just wants to do this:</div><div><br></div><div>unsafe {</div><div> FILE f = fopen(filename.toStringz, "rb");<br></div><div>}</div><div><br></div><div>There's no value in writing a whole function wrapper to automate a call to toStringz().<br></div><div>I'm not even sure that call is actually unsafe anyway. toStringz() isn't unsafe...?</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I further agree with you that would be good to have a clever way <br>
to declare @safe declarations for SOME function automatically <br>
declared by importC.<br></blockquote><div><br></div>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.</div><div class="gmail_quote">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.</div><div class="gmail_quote"><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
BTW, nice to see you here again in the forum, Manu! :-P<br></blockquote><div><br></div><div><font size="6">🎉 🎉 🎉</font></div><div><br></div></div></div>