ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-bugs: [Wireshark-bugs] [Bug 2812] Uninitialized variables (Lint Warning 603)

Date: Thu, 23 Oct 2008 09:29:29 -0700 (PDT)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2812





--- Comment #2 from Chris Maynard <christopher.maynard@xxxxxxxxx>  2008-10-23 09:29:28 PDT ---
For packet-acn.c, I think you nailed it.  I don't know much of this protocol so
I didn't know if perhaps the address information was actually available in the
case of ACN_ADDR_IPPORT, but the author just forgot to call SET_ADDRESS()
before the proto_item_append_text() like the other cases?  But if the address
is not available, then I think removing the call to address_to_str() and %s
formatting is probably the best solution there.

For packet-dnp.c, I don't know if a call to dnp3_al_get_timestamp() is the
answer there or not in the case of AL_OBJ_BIC_RTIME, similar to the AL_OBJ_TD +
AL_OBJ_TDCTO case.  Or quite possibly it's fine as it is since it's all wrapped
in a for() loop going back to line 1390 and perhaps you'll never see a case of
AL_OBJ_BIC_RTIME without a prior AL_OBJ_TD or AL_OBJ_TDCTO within this
protocol?  If so, maybe just initializing al_cto to zero is good enough?
Unfortunately, I don't know anything about dnp either to make a good enough
determination for the best fix here. :(

For packet-lapd.c, (the line #'s are off by 2 now in latest SVN), at first
glance, it looks like it could end up calling g_memdup() on some potentially
uninitialized data and passing it to tvb_new_real_data().  But after looking
again, perhaps this one is OK after all since the state is only ever set to
DATA when a new_byte() is added to the data[], so at least one valid byte
should be in data[]?  Maybe a memset(data, 0, sizeof(data)) or something is all
that is needed to quiet Lint ... or maybe just ignore this Lint warning
altogether?  Or maybe it is a problem?  I can't quite tell for certain.

For randpkt.c, ps_header is clearly not initialized ... but maybe that's
intentional because we're generating random packets?  I guess as long as
wtap_dump() doesn't care this it's not initialized, then this one could
possibly be ignored as well.  Or you could zero out the ps_header, which would
appease Lint.


-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.