First Draft: Making printf @safe (page 2)

On Wednesday, 17 July 2024 at 00:42:03 UTC, Walter Bright wrote: > https://github.com/WalterBright/documents/blob/ed4f1b441e71b5ac5e23a54e7c93e68997981e9a/SafePrintf.md Why not just make a @safe version of printf, and have a compiler error point people at it if they call unsafe printf from safe code?

On Friday, 2 August 2024 at 16:39:19 UTC, claptrap wrote: > On Wednesday, 17 July 2024 at 00:42:03 UTC, Walter Bright wrote: >> https://github.com/WalterBright/documents/blob/ed4f1b441e71b5ac5e23a54e7c93e68997981e9a/SafePrintf.md > > Why not just make a @safe version of printf, and have a compiler error point people at it if they call unsafe printf from safe code? This DIP doesn't only apply to C's printf, it (potentially) applies to other pragma(printf) functions. AIUI a major motivation for it is dmd's frontend which has a lot of calls to its own extern(C) functions with printf formatting strings and C varargs. (I'd be interested in seeing an alternative proposal too on how to make those calls safe without this DIP, whilst still compiling with GDC & LDC).

August 03

Re: First Draft: Making printf @safe

Posted by Nick Treleaven
in reply to Tim

Permalink

Nick Treleaven

Posted in reply to Tim

Permalink

On Saturday, 3 August 2024 at 15:28:35 UTC, Tim wrote:

One alternative would be a wrapper around printf, which checks the format string at compile time and modifies it and other parameters, so they match. It could look something like this:

void printfWrapper(string fmt, P...)(P params) @trusted
{
    // ...
}

void main() @safe
{
    string s = "World";
    printfWrapper!"Hello %s\n"(s);
}

There are 13 pragma(printf) functions in dmd. They could be changed. However, now those aren't functions but templates. I'm not sure if that's OK for ldc and gdc, maybe. And every call to each of those functions would need updating (unless we had enum parameters). The dmd as a library API would also be impacted, even if the original functions were kept as deprecated.

An advantage would be, that it could be used immediately in DMD. A new language feature could only be used after the bootstrap compiler is updated to this version, too.

Those functions could maybe be marked @trusted on the basis that the current dmd tests with the feature have checked all calls to them, and dmd as a library could require the new version of dmd for the API with the new @trusted functions.

On Saturday, 3 August 2024 at 17:12:15 UTC, Nick Treleaven wrote:

Yes, the change could be too big. I did not know how much it is used in DMD. The format string could also be checked or rewritten at runtime, but that would have other disadvantages.

That would work if the format string is only checked by the compiler. The DIP proposes, that it is also silently modified. Compiling DMD with an old bootstrap compiler could then contain a wrong format string.

On 8/2/2024 7:22 AM, Nick Treleaven wrote: > Dennis [has pointed out](https://forum.dlang.org/post/vnhnhkxxurgnpvpoilzp@forum.dlang.org) that this can corrupt memory (in a @system or @trusted function) just by simple refactoring: I replied to Dennis already.

Forums