Home • About Us • A-Z Index • Search * Contact Us • Register • Login • Press • Shop

The Open Brand -- Problem Reporting and Interpretations System

Problem Report 1216 Details

Help Show help | Quick Search | Submit a Test Suite Support Request | Click here to view your privileges

This page provides all information on Problem Report 1216.

Report 1216 Actions

    Problem Report Number 1216
    Submitter's Classification Test Suite problem
    State Resolved
    Resolution Rejected (REJ)
    Problem Resolution ID REJ.X.0418
    Raised 1970-01-01 08:00
    Updated 2003-03-13 08:00
    Published null
    Product Standard Internationalised System Calls and Libraries Extended (UNIX 95)
    Certification Program The Open Brand certification program
    Test Suite VSU version 4.1.0
    Test Identification CAPIbase/fdbm_fetch 4
    Problem Summary PG4U.00049 This was refused because it is a duplicate. See PIN4U.00006 instead.
    Problem Text
    This was refused because it is a duplicate. See PIN4U.00006 instead.

    fdbm_fetch/fdbm_fetch4
    fdbm_first/fdbm_first4
    fdbm_nextk/fdbm_nextk4

    These test cases fail because they write out 1024 byte records
    (variably-sized combinations of key and data).
    Our system and other Unix systems return an ENOSPC errno
    on records of this size. The maximum records we are able to
    write are 1017 bytes long. Here's why:

    We have ported our dbm source from CASPEC and this code
    has the identical behavior on other platforms we have seen.
    Several implementations have definitely used this CASPEC source.
    This behavior is apparently historical and current practice.
    Here is my understanding of the implementation details:

    The dbm routines have a data block of 1024 bytes long. The
    data block contains at least:

    1 key + 1 data + #entries + index_to_key#1 + index_to_key#2

    The #entries, and the index's are all shorts, so 2*3 = 6 bytes min.
    overhead per data block.
    If we change the block size, and other systems don't,
    then data files can't be easily moved. We can't use their
    dbm files and they cannot use ours.
    That's why we need to make doubly sure that this is the intention
    of the spec. Does the spec really mean the record must be
    1024+6 bytes overhead, versus 1024 including the size count overhead?

    Here is the wording from the spec:
    "These database functions support key/content pairs of at least 1024 bytes"
    Please advise, keeping in mind that changes to our implementation and
    other implementations to enlarge the data block size may break
    many existing applications. Remember too that it is likely that
    because of the age of the dbm_* functions, few new applications are
    written that make use of these old-style database functions, and that
    the primary usage is in old applications that are already in
    "production mode."
    Test Output
    10|580 /tset/CAPIbase/fdbm_fetch/fdbm_fetch4 16:49:16|TC Start, scenario
    15|562 1.10 1|TCM Start
    400|562 4 1 16:49:19|IC Start
    200|562 1 16:49:19|TP Start
    520|562 1 4849687 1 1|SPEC1170TESTSUITE CASE 4
    520|562 1 4849687 1 2|A call to datum dbm_fetch(DBM *db, datum key) shal
    520|562 1 4849687 1 3|support a maximum datum content and search key key
    520|562 1 4849687 1 4|pair size of atleast 1024 bytes.
    520|562 1 23461910 1 1|PREP: Create database
    520|562 1 23461910 1 2|PREP: Add records of max size 1024 to the databas
    520|562 1 23461910 1 3|1
    520|562 1 23461910 1 4|ERROR: dbm_store failed, errno = 133(ENOSPC - No
    220|562 1 2 16:49:20|UNRESOLVED
    410|562 4 1 16:49:20|IC End
    80|580 0 16:49:20|TC End

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    The submitter is correct but a recent ruling regarding this issue
    exists. To avoid the confusion duplicate rulings regarding the same
    might cause we recommend this request be refused and the submitter
    use PIN4U.00006 instead.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution Rejected (REJ)
    Review Conclusion
    This request is refused.

    Problem Reporting System Options:

     

    Back   

Contact the Certification Authority