Re: [GNUnet-developers] Catching printf mistakes / Refactoring vs Rust

[Martin Schanzenbach]

Hi,

On Wed, 2016-05-04 at 11:16 +0200, carlo von lynX wrote:
> I just noticed this bugfix. Thanks, Bart, for finding it!
> 
> On Tue, May 03, 2016 at 08:38:45PM +0200, address@hidden wrote:
> >    if (size != ntohs (msg->size))
> >    {
> >      LOG (GNUNET_ERROR_TYPE_WARNING,
> > -         "UDP malformed message header from %s\n",
> > +         "UDP malformed message (size %u) header from %s\n",
> >           (unsigned int) size,
> >           GNUNET_a2s (sa,
> >                       fromlen));
> 
> But it occurs to me... this is a bug that should be
> automatically detectable by a software that checks the
> number and type of arguments with the %'s in the string.
> Doesn't gcc complain?
> 
I think gcc complains if -Wformat is set. And that is a feature as
prinf is declared as something like
"int printf(const char *, ...)"
A "wrong" use of prinf e.g. "printf("%s %d", x); is still perfectly
valid from a semantical point of view.

To detect this error the first argument would have to be parsed and
checked against the variable number of following arguments (and their
types, actually!). So this requires a special feature in the compiler
as this is not part of the C standard.

As a side note, -Wformat still sucks in terms of usefulness. But at
least you get a warning...

- Martin

> // Optional extended read:
> 
> Aside from that I'm not sure if it still is appropriate
> in this day and age to use the old printf paradigm. Ok
> for logging, but suboptimal for the usability of user
> interaction.
> 
> PSYC uses named parameters, allowing for more precise
> consistency checks and language internationalization
> that does not need to maintain the order of arguments.
> Example:
> 
> psycsay( "_warning_syntax_transport_size",
>     "[_transport_name] malformed message (size [_numeric_size]) "\
>     "header from [_keydress]", {
>       "_transport_name_datagram": "UDP",
>       "_numeric_size_datagram", (unsigned int) size,
>       "_keydress_peer": GNUNET_a2s (sa, fromlen) } );
> 
> It also allows for variable name inheritance, which
> allows the applications to selectively use standardized
> output messages for entire families of error messages,
> or to use specific output strings where appropriate
> without necessarily having to edit the source code.
> It's all in the multilingual textdb which holds the
> string formats. Yes that means also replacing the
> historic gettext() hack with something that doesn't use
> the english language as a look-up value.
> 
> But migrating away from gettext in gnunet is probably
> a refactoring job as big as rewriting it in Rust.
> Does Rust do these things much better? Or does
> "rewriting it in Rust" bear a risk of simplification
> for not identifying exactly *what* deserves 
> refactoring and what doesn't?
> 
>