Hi Joerg,
On Mon, Oct 21, 2013 at 11:58:17PM +0200, Joerg Mayer wrote:
> Looks like coverity has a valid complaint:
>
> CID 1109702: Dereference after null check (FORWARD_NULL)
>
> /tshark.c: 2859 ( var_compare_op)
> 2856 /* If we're going to print packet information, or we're going to
> 2857 run a read filter, or we're going to process taps, set up to
> 2858 do a dissection and do so. */
> >>> Comparing "edt" to null implies that "edt" might be null.
> 2859 if (edt) {
> 2860 if (gbl_resolv_flags.mac_name || gbl_resolv_flags.network_name
> ||
> 2861 gbl_resolv_flags.transport_name ||
> gbl_resolv_flags.concurrent_dns)
> 2862 /* Grab any resolved addresses */
> 2863 host_name_lookup_process();
>
>
> /tshark.c: 2903 ( var_deref_model)
> 2900 if (print_packet_info) {
> 2901 /* We're printing packet information; print the information
> for
> 2902 this packet. */
> >>> Passing null variable "edt" to function "print_packet", which
> >>> dereferences it.
> 2903 print_packet(cf, edt);
> 2904
> 2905 /* The ANSI C standard does not appear to *require* that a
> line-buffered
> 2906 stream be flushed to the host environment whenever a
> newline is
> 2907 written, it just says that, on such a stream, characters
> "are
I don't see a problem.
Previously print_packet() was also passing edt as NULL
- if (do_dissection)
- print_packet(cf, &edt);
- else
- print_packet(cf, NULL);
I simplified it, just to:
+ print_packet(cf, edt);
No idea how to fix it, sorry. Most likely it's false positive.
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <[email protected]>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:[email protected]?subject=unsubscribe
