Ethereal-dev: Re: [Ethereal-dev] New PROFINET dissector(s), first part checked in!

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Ulf Lamping" <ulf.lamping@xxxxxx>
Date: Wed, 08 Dec 2004 13:45:35 +0100
Ethereal development <ethereal-dev@xxxxxxxxxxxx> schrieb am 07.12.04 19:16:32:
> 
> Some warnings:
> 
> 	packet-pn-rt.c: In function `dissect_pn_rt':
> 	packet-pn-rt.c:325: warning: cast to pointer from integer of different size
I might need to cast the u16 to an u32. But first I've noticed, that I have to use GUINT_TO_POINTER instead of GINT_TO_POINTER which might solved this already (well, probably not).

> 	packet-pn-rt.c:117: warning: `u8DataStatus' might be used uninitialized 
> in this function
> 	packet-pn-rt.c:118: warning: `u8TransferStatus' might be used 
> uninitialized in this function
> 	packet-pn-rt.c:119: warning: `u16CycleCounter' might be used 
> uninitialized in this function
> 
> I'm not sure what you can do about the pointer cast; are the others 
> variables that won't, in practice, be uninitialized, but GCC's dataflow 
> analysis isn't sophisticated enough to discover that?
Exactly. I've added an "unrequired" initialization in the else part which should satisfy gcc here (didn't found a better way).

> 
> > - PN-DCP: using PN-RT
> 
> It gets some warnings:
> 
> 	packet-pn-dcp.c: In function `dissect_PNDCP_Block':
> 	packet-pn-dcp.c:701: warning: zero-length printf format string
> 	packet-pn-dcp.c: In function `dissect_PNDCP_Data_heur':
> 	packet-pn-dcp.c:847: warning: zero-length printf format string
> 
> If the idea is that it starts out empty and then gets stuff appended to 
> it, you might want to restructure that so that it's not empty if the 
> dissector throws an exception (due to a short packet) before anything 
> gets appended to it.
> 
For the first one I've simply added the prefix "Block: " which is a good idea at all.

The second one is a bit more tricky. I'm not sure what's the right solution to this. 

The alternative: If there's a short packet which would simply append the string "Get", this might also not be very informational.
I've simply fixed it, by exchanging the empty string instead of appending it (however, that's still not perfect).


I've noticed another warning in packet-pn-io.c, which I've fixed too.


I will keep an eye on the gcc warnings in these files.

BTW: the buildbot is a good way to find warnings for platforms you don't have at hand :-)

Regards, ULFL

__________________________________________________________
Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min.
weltweit telefonieren! http://freephone.web.de/?mc=021201