Notes from C++ static analysis

Andrej Mitrovic andrej.mitrovich at gmail.com
Wed Jun 26 20:26:05 PDT 2013


On 6/27/13, Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org> wrote:
> Apologies for the overly curt reply, which I have now canceled. OK let's
> do this: aside from sarcasm, do you have good arguments to line up to
> back up your opinion?

format has thrown exceptions with such code since v2.000 (that's the
year 2007). It's only in v2.061 that it has finally gotten an
informative error message in the exception it throws.

I'm not against having the current lax argument count handling feature
for writef, but for format it's enabled me to catch bugs at the call
site.

The way I see it, write/writef is primarily used for debugging and
benefits having some lax features, whereas format is used in more
heavy-duty work where it's important not to screw things up at the
call site.

As for the unittesting argument (if the argument applies to format),
in theory the argument is perfectly sound and I agree with you, but in
the real world convenience trumps manual labor. We should unittest
more, but it's super-convenient when format tells you you've screwed
something up when you're e.g. writing some D-style shell scripts or
when porting C code to D, maybe you don't have a lot of time to
unittest constantly.

---

But the bottom line is I don't think we need to force anything on
anybody. If anything, we could split up the internal format
implementation and provide format and safeFormat functions.

format("%s %s", 1);  // no exceptions
safeFormat("%s %s", 1);  // exception thrown

All current code will de-facto still work (because otherwise they
would already get runtime exceptions), and all future code could start
using safer formatting functions.

We could have that, or some getopt-style configuration options, such as:

format("%s %s", std.format.config.safe, 1);

Or some other form of wizardry (perhaps a compile-time argument).

Anything goes. Let's not break too much sweat arguing for what should
ultimately be a customization point.


More information about the Digitalmars-d mailing list