[pcap-ng-format] Section length in the SHB

[Jasper Bongertz]

Agree, let's go for signed 64-bit here.

BTW, I have never seen a pcapng file actually using a value other than
0xFFFFFFFFFFFFFFFF, because total length is usually yet unknown while
starting to write the file (and no program seems to bother to update
it after writing the final byte :-))

on Mittwoch, 26. August 2015 at 23:20 you wrote:

> Currently, the spec says:

>         Section Length: a signed 64-bit value specifying the length
> in bytes of the following section, excluding the Section Header
> Block itself. This field can be used to skip the section, for faster
> navigation inside large files. Section Length equal -1
> (0xFFFFFFFFFFFFFFFF) means that the size of the section is not
> specified, and the only way to skip the section is to parse the
> blocks that it contains. Please note that if this field is valid
> (i.e. not negative), its value is always aligned to 32 bits, as all
> the blocks are aligned to and padded to 32-bit boundaries.

> Before Hadriel's change, it said:

>         Section Length: 64-bit value specifying the length in bytes
> of the following section, excluding the Section Header Block itself.
> This field can be used to skip the section, for faster navigation
> inside large files. Section Length equal -1 (0xFFFFFFFFFFFFFFFF)
> means that the size of the section is not specified, and the only
> way to skip the section is to parse the blocks that it contains.
> Please note that if this field is valid (i.e. not -1), its value is
> always aligned to 32 bits, as all the blocks are aligned to and padded to 32-bit boundaries.

> and his comment in response to a question was:

>         I was actually going to change the whole thing to say it's
> an *unsigned* 64-bit value, and max value (0xFFFFFFFFFFFFFFFF) meant
> "unknown" but any other value was the length of the section. But I
> thought that might be a controversial change. So I changed it to
> this because the previous wording implied other negative numbers
> were valid lengths, which clearly they're not.

> The previous warning was unfortunate, as it didn't *explicitly* say
> "signed 64-bit value", but, by speaking of -1 rather than
> 0xFFFFFFFFFFFFFFFF or 18446744073709551615, it at least suggested that it be signed.

> So I'm not sure whether explicitly declaring it to be unsigned would be a problem or not.

> If it would, we need to say what should be done for negative values
> other than -1.  Fail?  Treat *all* negative values as meaning "unknown"?

> If it wouldn't, I'd vote for making it unsigned, and saying that
> 0xFFFFFFFFFFFFFFFF means "unknown" and not speaking of -1. (Note
> that increasing the maximum specifiable size from
> 9223372036854775807 to 18446744073709551615, by going to unsigned,
> is likely to make a difference any time soon; if we ever get to the
> point where we have technologies for storing files with more than
> 9223372036854775807 bytes, I'm sure we can go with pcapng 2.0 and a
> 128-bit or larger section size. :-))
> _______________________________________________
> pcap-ng-format mailing list
> pcap-ng-format at winpcap.org
> https://www.winpcap.org/mailman/listinfo/pcap-ng-format
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4015 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://www.winpcap.org/pipermail/pcap-ng-format/attachments/20150826/1f14c870/attachment-0001.bin>