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.
