https://issues.dlang.org/show_bug.cgi?id=8471

Andrei Alexandrescu <andrei@erdani.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |bootcamp

--

https://issues.dlang.org/show_bug.cgi?id=8471

Jakub Łabaj <uaaabbjjkl@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |uaaabbjjkl@gmail.com

--- Comment #4 from Jakub Łabaj <uaaabbjjkl@gmail.com> ---
According to Steven's blog post (http://dlang.org/blog/2016/09/28/how-to-write-trusted-code-in-d/) I should "never use @trusted on template functions that accept arbitrary types". Is the readf case special in this regard?

--

https://issues.dlang.org/show_bug.cgi?id=8471

--- Comment #5 from Andrei Alexandrescu <andrei@erdani.com> ---
(In reply to Jakub Łabaj from comment #4)
> According to Steven's blog post (http://dlang.org/blog/2016/09/28/how-to-write-trusted-code-in-d/) I should "never use @trusted on template functions that accept arbitrary types". Is the readf case special in this regard?

If readf calls user-defined functions (constructor, assignment) then yes that's a problem. The smoking gun would be an unsafe unittest that passes with the current implementation. Can you write one?

--

https://issues.dlang.org/show_bug.cgi?id=8471

--- Comment #6 from Jakub Łabaj <uaaabbjjkl@gmail.com> ---
Currently I see one way to break the safety, which is to not pass a real pointer, but a structure with unary '*' overloaded:

@safe unittest
{
    struct Unsafe
    {
        int* x;
        ref int opUnary(string s)() if (s == "*")
        {
            int y;
            // int* ptr = &y; // not @safe
            return *x;
        }
    }
    static int x;
    static Unsafe unsafe;
    unsafe.x = &x;
    string text = "10";
    formattedRead(text, "%d ", unsafe); // called by readf
    assert(*unsafe.x == 10);
}

Probably I can't mess up assignment operator nor constructor, because only builtin types are parsable (constrained by function unformatValue). So I think making formattedRead / readf accepting only pointers to builtin types is a way to make them @trusted.

--

https://issues.dlang.org/show_bug.cgi?id=8471

--- Comment #7 from Andrei Alexandrescu <andrei@erdani.com> ---
Cool, thanks, then the bug is legit. The fix would be a @safe function with a small @trusted core.

--

https://issues.dlang.org/show_bug.cgi?id=8471

--- Comment #8 from Jakub Łabaj <uaaabbjjkl@gmail.com> ---
Sorry, I'm not sure what you mean by that - what are the next steps to do here?

--

https://issues.dlang.org/show_bug.cgi?id=8471

--- Comment #9 from Andrei Alexandrescu <andrei@erdani.com> ---
(In reply to Jakub Łabaj from comment #8)
> Sorry, I'm not sure what you mean by that - what are the next steps to do here?

I think Razvan Nitu has reached out to you on how to go about creating PRs.

--

https://issues.dlang.org/show_bug.cgi?id=8471

--- Comment #10 from Jakub Łabaj <uaaabbjjkl@gmail.com> ---
I know how to create PRs, I've already created some. What I mean is I'm not sure how you see the solution, e.g. '@safe function with a small @trusted core', could elaborate on this, please?

--

https://issues.dlang.org/show_bug.cgi?id=8471

--- Comment #11 from Andrei Alexandrescu <andrei@erdani.com> ---
Oh, sorry. The idea is to leave readf unqualified and let the compiler infer whether it's safe or not.

In this particular case I see there's a simple solution - just add a constraint to it making sure all parameters are pointers. Something like:

uint readf(Data...)(in char[] format, Data data)
if (allSatisfy!(isPointer, Data);

Then the only way to call readf is with pointers, which eliminates the possibility of shenanigans.

--

https://issues.dlang.org/show_bug.cgi?id=8471

--- Comment #12 from Andrei Alexandrescu <andrei@erdani.com> ---
@Jakub, what's your github id? thx!

--