[EMAIL PROTECTED] writes: > On Wed, 11 Jun 2008, James Carlson wrote: > > The distinction would be between considering -1 to be a design flaw on > > the part of the caller, or part of the input range requiring a valid > > response. > > In the case of the driver I'm talking about, it's part of the input range > (which here truly spans 0...UINTMAX_MAX, per specification).
There's no way a specification can demand that we build a system with 18 exabytes of RAM. > > I think you might need to back up a bit: who is calling this caller? > > And where did the erroneous -1 come from originally? > > Input from a file, and the size field in question, as per specification of > the file format, can have any value allowed for an unsigned 64bit integer. > > It seems to me that the driver, from its point of view, does the right > thing - do a best-possible attempt via KM_NOSLEEP if it finds the size > field too large. Adding another "way too large" check seems wrong, who > says what's "way too large" ... You could simply say that anything with the upper bit set is "too large." That'll work fine until we have 64-bit CPUs with 9 exabytes of RAM installed ... and I'd _assume_ that either the CPUs or the spec would be rev'd before then. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
