Closed
Bug 329728
Opened 19 years ago
Closed 19 years ago
Coverity doesn't like main in xpt_link because it pretends header could be null
Categories
(Core :: XPCOM, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: timeless, Assigned: timeless)
References
(Blocks 1 open bug)
Details
(Keywords: coverity)
Attachments
(1 obsolete file)
header *can't* be null, as XPT_DoHeader will return false when it sets header to null which means we take the early exit.
Attachment #214401 -
Flags: superreview?(bzbarsky)
Attachment #214401 -
Flags: review?(mrbkap)
Comment 2•19 years ago
|
||
Comment on attachment 214401 [details] [diff] [review]
try to quiet coverity by not null checking something that won't be null
sr=bzbarsky, but I really don't know this code. Shouldn't shaver be in on this?
Attachment #214401 -
Flags: superreview?(bzbarsky) → superreview+
shaver didn't want to deal w/ the noise last night, so i've been a bit shy.
Comment 4•19 years ago
|
||
I have to ask, what is Coverty and why doesn't it like null checks?
How about changing it to an assert to enforce the fact that it can't/shouldn't be null. If Coverty doesn't like that, smack it a good one for me.
http://scan.coverity.com it's a static analyzer. you can browse through bugzilla for bugs w/ the coverity keyword to see other examples of things it finds.
in general, coverity is at the whim of the build style you choose, so if you try building disable-debug and asserts are replaced by empty, then coverity will ignore them. (whereas if you build w/ enable-debug, coverity would understand them....) i have no idea how this public coverity was configured (and i've never actually watched someone configure coverity, so this is just an impression), my guess is that it'd have been configured disable-debug so while we can assert, i'd imagine it'd ignore us.
in this case, i don't see the point of asserting, it's just the way the functions work, no mystery. compare that to some other bugs where there are very long call chains with fairly disconnected assumptions.
Status: NEW → ASSIGNED
Comment 6•19 years ago
|
||
I'm just going on the fact that the original author thought it was worth the effort to put in the check. I imagine nisheeth was just be cautious. I'd be curious to know why Coverty thinks this null check is bad. Is it the subsequent use of header without the null check that it's really concerned with?
The correct solution is for XPT_DoHeader to assert the post condition. If we're going to put effort into this, wouldn't it be nice to get a little more out of it than just quieting some noise?
Comment 7•19 years ago
|
||
Comment on attachment 214401 [details] [diff] [review]
try to quiet coverity by not null checking something that won't be null
Yeah, this is right.
Attachment #214401 -
Flags: review?(mrbkap) → review+
Comment on attachment 214401 [details] [diff] [review]
try to quiet coverity by not null checking something that won't be null
mozilla/xpcom/typelib/xpt/tools/xpt_link.c 1.34
yeah, coverity complains about the inconsistency. the decission about which is right is something that we get to figure out.
Attachment #214401 -
Attachment is obsolete: true
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Updated•6 years ago
|
Blocks: coverity-analysis
You need to log in
before you can comment on or make changes to this bug.
Description
•