Re: [Libcdio-devel] New git branch for bug 45017 ? Or re-use branch for 45015 ?

[Thomas Schmitt]

Hi,

Rocky Bernstein wrote:
> Return true if this is not a directory record and  false if not.

Yes, that's about half of the story we need to tell.
The other half could be:

  If true is returned, then offset contains the byte offset of the
  next unverified directory record candidate. Especially it is not
  verified that the offset is still within the size of the directory.

The first sentence mentions the important side effect of the call.

The second sentence implies that one first has to check the loop condition
of the caller, if there is a loop. This is the pitfall which i want
to bring to the attention of future programmers.
(If the offset is still inside the directory, then it should bear a
 valid directory record, because each block of a directory is supposed
 to start with a directory record start.)


Rocky Bernstein wrote:
> > > - Alleged directory record spans over block limit.
> > > + Directory record spans over block limit.

i wrote:
> > It is not a directory record.

Rocky Bernstein proposed:
> Bytes read span over directory record block limit.

It's not really about the bytes which were read. (Dunno whether libcdio
already has read them at this point.)

The one byte in question, if interpreted as the first byte of a directory
record, would indicate a record length that spans over the block limit.
This violates the specs and thus proves that the byte is not part of a
valid directory record.

So the potential directory record is proven to be only an alleged one,
but indeed is something else, which we better do not interpret.

How about:

  This is not a directory record, because it would span over the next
  block limit.


> I've asked several times in what since is this "rounded"?

I refer to the arithmetic operation of rounding. Hopping to the next block
is nearly the same as rounding up the byte address divided by the block size
to the next integer and to then multiply the result by the block size.

The only difference is in the special case when the offset is already
aligned to the block size. In that case, rounding would yield no change
of offset and thus an endless cycle in the calling loop.

But as said, if this "nearly rounding" does not come to your mind
when seeing that code, then the comment is not needed.

You could also adopt the Linux formula and simply state that it works
there for more than 20 years.
(That formula looks not like rounding. It needs some thought to
 make the connection to mine. Mine is arithmetic, Linux' is partly
 bit pattern manipulation.)


Have a nice day :)

Thomas