[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: format ‘%lu’ expects type ‘long unsigned int’, but argument 5 has type ‘uintptr_t’
- To: or-dev@xxxxxxxxxxxxx
- Subject: Re: format ‘%lu’ expects type ‘long unsigned int’, but argument 5 has type ‘uintptr_t’
- From: Nick Mathewson <nickm@xxxxxxxxxxxxx>
- Date: Sat, 20 Nov 2010 05:23:05 -0500
- Delivered-to: archiver@xxxxxxxx
- Delivered-to: or-dev-outgoing@xxxxxxxx
- Delivered-to: or-dev@xxxxxxxx
- Delivery-date: Sat, 20 Nov 2010 05:23:14 -0500
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=fPD40i4yf6Q6NnewwIBzdS8hSmVzVDf256QJ3/Jp3LU=; b=v1Cv76wgzDpBKWwweVYbuX8GflW+/rukJTP5ecFShvJbbgt8uLzGQBswpa4EyA7lM3 fAll8OBZd5qShOvkh4h3/BFh71MisbhZN0TCEMSG9YwG8MnWgn4LaSWRR1nY+puPxgwA JOnXn0QuYj/Qrjp1HV/NFqaSXQL1f5AeDXrag=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=YD2eQWwAgJZkmMXEejqV7KwSltUduokwMUyFBYKI6StrQvppdwLX88Usu5+N+zF7L3 GkqNSJD4AO01kpaJsgx7qxpLgpT1SU8kTm3grMFhmg6Q5fpSLlU8VDHS+F8kBiK1sEOO VHDsNIwoHHJLu5kNvjQx4Oee/wo5xAU3dbEQg=
- In-reply-to: <alpine.DEB.2.01.1011200127100.29030@xxxxxxxxxxxxxx>
- References: <alpine.DEB.2.01.1011200127100.29030@xxxxxxxxxxxxxx>
- Reply-to: or-dev@xxxxxxxxxxxxx
- Sender: owner-or-dev@xxxxxxxxxxxxx
On Sat, Nov 20, 2010 at 5:07 AM, Christian Kujau <lists@xxxxxxxxxxxxxxx> 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