gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: carlo von lynX
Subject: [GNUnet-developers] Catching printf mistakes / Refactoring vs Rust
Date: Wed, 4 May 2016 11:13:55 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

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?

// 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?


-- 
  E-mail is public! Talk to me in private using encryption:
         http://loupsycedyglgamf.onion/LynX/
          irc://loupsycedyglgamf.onion:67/lynX
         https://psyced.org:34443/LynX/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]