grothoff@pixel:~/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 */ void -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, [email protected] 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? > >
0xE29FC3CC.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
