Nicholas Clark wrote:
On Thu, Dec 11, 2008 at 01:15:05PM -0800, [email protected] wrote:
Author: cotto
Date: Thu Dec 11 13:15:04 2008
New Revision: 33810
Modified:
trunk/src/packfile/pf_items.c
Log:
[packfile] fix CID #160, since sizeof (opcode_t) is not likely to be 0
What the heck did Coverity's scanner find objectionable about return s ? s : 1;
?
It reported the 1 branch as dead code on the assumption that s is never 0.
size_t
PF_size_integer(void)
{
- const size_t s = sizeof (INTVAL) / sizeof (opcode_t);
- return s ? s : 1;
+ return sizeof (INTVAL) / sizeof (opcode_t);
}
Specifically, the ternary is valid and useful if sizeof (opcode_t) is
greater than twice sizeof (INTVAL). Are the types of both fixed in C code
that Coverity's scanner can see, or are they determined by Configure.pl?
If the latter, then I believe that Coverity's scanner is in error here, as it
can't know whether (say) it's dealing with 4/16, or 2/8, which is 0 in C.
Nicholas Clark
On my system they're both long (opcode_t -> Parrot_Opcode -> long, INTVAL ->
Parrot_Intval -> long), but they're generated by Configure.pl in
include/parrot/config.h . Digging through config/ it seems likely that
they're always the same (they are by default and on my system), but I don't
know the config system well enough to be certain in all cases.
If someone could shed some light on this, it'd be good to know if the 1 branch
could realistically be hit or if r33810 should remain unchanged.
