Re: format ‘%lu’ expects type ‘long unsigned int’, but argument 5 has type ‘uintptr_t’

[Nick Mathewson]

On Sat, Nov 20, 2010 at 5:07 AM, Christian Kujau <lists at nerdbynature.de> wrote:
> Hi,
>
> while compiling the today's git tree (e361de80bb), I get the following
> error when compiling (gcc 4.3.2, powerpc32):
>
> ----------------------------------------------------
> control.c: In function ‘control_event_signal’:
> control.c:3621: error: format ‘%lu’ expects type ‘long unsigned int’, but argument 5 has type ‘uintptr_t’
> make[3]: *** [control.o] Error 1
> make[3]: Leaving directory `/usr/local/src/tor-git/src/or'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory `/usr/local/src/tor-git/src'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/usr/local/src/tor-git'
> make: *** [all] Error 2
> ----------------------------------------------------
>
> Reverting 7441999738e7c1b0ea94a39dd6e1f8a48043ff7d ("Add a SIGNAL event
> for control connections") seems to help. Also, changing %lu to %u in
> src/or/control.c helps too, but I don't know if this is the right thing to
> do - at all. Please check.

Thanks, and thanks for the excellent bug report.  This should be fixed now.

The problem was that the new code to report SIGNAL events to the
controller used %u to format a uintptr_t for display to the logs in
the case where the signal number was unknown.  Neither %u now %lu is
quite right for uintptr_t, since that type will be the same slze as
unsigned int on  some architectures, but the same size as unsigned
long on others.  Since the log message is triggered only on a bug, it
should be good enough to display the wider type unconditionally: hence
see 9cbe64db45de6d6f5.

Thanks again,
-- 
Nick