Comments below
________________________________________________________________________
_____
OBJECTION Enhancement Request
Number 103
yyyyyy@xxxxxxxxxxxxx Bug in xsid5 Assorted (rdvk#
142)
[DST-337] Mon, 5 Feb 2001 19:57:19
-0800
________________________________________________________________________
_____
Accept_____ Accept as marked below_X___ Duplicate_____
Reject_____
Rationale for rejected or partial changes:
The size of the record (key/content) must never exceed the block size.
>>> With the reordering below, this helps, but its still necessary to
infer
more than desireable from the page in this regard.
There is no guarantee here and portable
applications can only assume a minimum size for the block size to
support
key/content pairs of up to 1023 bytes.
These are clear warnings to the customer that under undefined conditions
these interfaces may not work.
>>> Like what? "Always" is a reasonable "undefined condition". (Not
useful,
but reasonable.)
The following changes should be made to the draft:
Change the first paragraph at 8347
If the sum of a key/content pair exceeds the internal block size, the
result
is unspecified.
>>> That helps, but not completely. At line 8348, there's a TASA that
says
the application should prevent size overflow for the sum of ALL entries
that hash
together. However, since the hash function is not defined, the
application doesn't
have the proverbial snowball's chance of doing that. Minimally, that
should be
changed so the application writer is informed that such an error can
occur, but
we don't give the application ANY way to recover if it does occur.
>>>All this makes me wonder if the page should be completely rewritten
from
a user's point of view, or if it should possibly be dropped. (I don't
have any
objection to dbm_* in itself, simply that given what I've seen so far,
this page
makes me nervous that there are other language traps we haven't found
yet that
might make implementation or use (in a strictly standard conforming way)
either
useless or impossible.)
move 8456-8457 to before 8420 (separate para)
>>> That's very helpful, in that it gets concepts in the right order.
Donn
|