On Jun 2, 2013, at 6:07 PM, eapache@xxxxxxxxxxxxx wrote:
> Initialize some variables that GCC 4.7 complains about. I'm not 100% sure
> that the complaints are valid,
For hdr_info.length, they're not - we error out if there's no length field.
For hdr_info.sliceLength, they are.
> or that simply zeroing them is the right fix if they are,
It's the best workaround for compilers whose dataflow analysis isn't sophisticated enough.
> but at least it builds now. Should we be erroring if we don't
> see a sliceLength header?
I'm not sure - currently, now that hdr_info.sliceLength is zeroed before we look at the attribute/value pairs, and given that, if it's zero, we assume no slicing, the code works.
We don't have a published spec for the file format, so we don't know whether the slice length attribute is optional or not.
(In the hopes of preempting replies saying "WildPackets does publish the file format, see their PeekRdr application", note that this page:
https://mypeek.wildpackets.com/view_solution.php?id=26
says "You must have a valid maintenance contract to download this file." Unless there's some way to download a description of the file format *without* purchasing OmniPeek or a maintenance contract for it, or a way for somebody who has downloaded it to *legally* provide us with it - e.g., if you signed some form of non-disclosure agreement when you purchased OmniPeek or the maintenance contract and that NDA covers that document, or if the document says "you can't give this away" or "you can only give this away to people who have a maintenance contract for OmniPeek", that's of no use to us.)
