[Top][All Lists]

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

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

From: Christian Grothoff
Subject: Re: [GNUnet-developers] Catching printf mistakes / Refactoring vs Rust
Date: Wed, 4 May 2016 11:23:48 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.6.0

address@hidden:~/svn/gnunet$ svn diff
Index: src/include/gnunet_common.h
--- src/include/gnunet_common.h (revision 37119)
+++ src/include/gnunet_common.h (working copy)
@@ -386,7 +386,8 @@
  * @param ... arguments for format string
-GNUNET_log_nocheck (enum GNUNET_ErrorType kind, const char *message, ...);
+GNUNET_log_nocheck (enum GNUNET_ErrorType kind, const char *message, ...)
+  __attribute__ ((format (printf, 2, 3)));

 /* from glib */
 #if defined(__GNUC__) && (__GNUC__ > 2) && defined(__OPTIMIZE__)

=> SVN 37120.

Now just somebody needs to fix the format string warnings we now get ;-).

On 05/04/2016 11:16 AM, 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))
>>    {
>> -         "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?

Attachment: 0xE29FC3CC.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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