Yes, I think you’re right. I was too
focused on msp itself. If ipfd_head is not NULL
then I don’t see any way for msp to be NULL either. Sorry,
false alarm.
From:
wireshark-dev-bounces@xxxxxxxxxxxxx
[mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On
Behalf Of Sébastien Tandel
Sent: Friday, August 15, 2008 9:47
AM
To: Developer support list for
Wireshark
Subject: Re: [Wireshark-dev] Lint
of packet-tcp.c
On Fri, Aug 15, 2008 at 2:30 AM, Jaap Keuter <jaap.keuter@xxxxxxxxx> wrote:
Hi Chris,
Thanks for taking a look. I looked at your new log also, and still wonder how
lint get these 'Possible use of null pointer' results. Use of msp is guarded by
ipfd_head, so this should never cause a problem. I wonder what lint sees as
path
to get in trouble.
desegment_tcp (... struct tcp_analysis *tcp)
ipfd_head = fragment_add();
it is already not a so simple inspection path to check that if
ipfd_head != NULL, it implies that msp != NULL ... even for a human! :-p
I don't think it costs a lot to have something like the following for
the last "if" of the excerpt :
and it should let lint happy ... and humans too héhé ;)
Furthermore, gcc already eliminates useless checks for NULL pointers ;)
-fdelete-null-pointer-checks
Use global dataflow analysis
to identify and eliminate useless
checks for null pointers.
The compiler assumes that dereferencing
a null pointer would have
halted the program. If a pointer is
checked after it has already
been dereferenced, it cannot be null.
In some environments, this
assumption is not true, and programs can
safely dereference null
pointers. Use
-fno-delete-null-pointer-checks to disable this optimization for
programs which depend on that
behavior.
Enabled at levels -O2, -O3, -Os.
CONFIDENTIALITY NOTICE: The contents of this email are confidential
and for the exclusive use of the intended recipient. If you receive this
email in error, please delete it from your system immediately and
notify us either by email, telephone or fax. You should not copy,
forward, or otherwise disclose the content of the email.
|