[pcap-ng-format] opt_endofopt unnecessary?

[Jasper Bongertz]

On 10.05.2012 20:25, Guy Harris wrote:
> Section 2.5 "Options" of the pcap-NG spec says:
>
>> Skipping all the optional fields at once is straightforward because most of the blocks are made of a first part with fixed format, and a second optional part. Therefore, the Block Length field (present in the General Block Structure, see Section 2.1) can be used to skip everything till the next block.
> This also means that the Block Length field can be used to determine the number of bytes of options in the block.  That also means that the Block Length field can be used to determine when you're at the end of the block when scanning options, so there doesn't need to be an opt_endofopt option at the end of the list of options to mark the end.

Correct. Having an opt_endofopt option is not really necessary, but I
have to admit it is a quick and easy (okay, maybe even lazy) way to code
an exit strategy when scanning options.
> Furthermore, any robust pcap-NG reading code has to stop processing options when it runs out of bytes in the block, regardless of whether there's an opt_endofopt option, so that option doesn't simplify the option parsing code.

Agreed. As painful it may be to handle incomplete blocks, but it is
necessary nonetheless to have robust code. And reading incomplete blocks
is something the code has to do for all parts of the file read process
anyway, so why stop at reading options...
> The spec doesn't explicitly say opt_endofopt is required, it just says "It delimits the end of the optional fields."
>
> My inclination would be to deprecate it, so that a reader:
>
> 	must not assume it's present (which is the case anyway, even if it gives an error if it's not present, as a reader has to handle malformed files without crashing or doing anything else wrong by reading past the end of the block);
>
> 	must not return an error if it's absent;
>
> 	must stop parsing options if it's present (in case some app writes one out and then has other junk past it in the block).
Doesn't "deprecate" also mean "should not be used anymore when writing
files"? At least that's what I would think it means, but I'm not a
native speaker. For me, the gain of completely deprecating opt_endofopt
would be to make each option block a few bytes smaller, but I'm not sure
if that is significant enough to prevent writing it at all. Maybe it can
be optional (which is kind of a funny thing since we're talking about
options anyway, so I guess it is already sort of optional :-))