[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #8447 [Tor]: p_circ_id is a uint32_t, but we print it as a %d
#8447: p_circ_id is a uint32_t, but we print it as a %d
-----------------------+----------------------------------------------------
Reporter: arma | Owner:
Type: defect | Status: new
Priority: normal | Milestone: Tor: 0.2.4.x-final
Component: Tor | Version:
Keywords: tor-relay | Parent:
Points: | Actualpoints:
-----------------------+----------------------------------------------------
Comment(by nickm):
It's cosmetic in practice, but it's technically undefined behavior, so we
should fix it.
At least, the way I read the C standard, it's undefined: integer arguments
passed to a variable-arguments function as variable arguments are subject
to the "default argument promotions", which mean that any thing smaller
than int gets promoted to int. So if int is 64-bit, we're fined: uint32_t
can get promoted to int without trouble. But if int is 32-bit, uint32_t
stays where it is. The standard says:
{{{
If there is no actual next argument, or if type is not compatible with the
type of the
actual next argument (as promoted according to the default argument
promotions),
the behavior is undefined, except for the following cases:
- one type is a signed integer type, the other type is the
corresponding unsigned
integer type, and the value is representable in both types;
}}}
so I don't think we're strictly speaking in the clear.
In practice, this won't hurt in any way I can tell, but we shouldn't
tolerate undefined behavior lightly.
I wonder why GCC isn't warning about this?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/8447#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs