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

The Open Brand -- Problem Reporting and Interpretations System

Problem Report 2736 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 2736.

Report 2736 Actions

    Problem Report Number 2736
    Submitter's Classification Test Suite problem
    State Resolved
    Resolution Rejected (REJ)
    Problem Resolution ID REJ.X.0701
    Raised 2021-12-14 08:32
    Updated 2022-03-03 06:38
    Published 2022-03-03 06:38
    Product Standard Commands and Utilities V4 (UNIX 03)
    Certification Program The Open Brand certification program
    Test Suite VSC version 5.3.21NW
    Test Identification tset/XOPEN.cmd/nl/nl.ex #1042
    Specification Shell and Utilities Issue 6
    Location in Spec https://pubs.opengroup.org/onlinepubs/009695399/utilities/nl.html
    Problem Summary assertion 1042 of tset/XOPEN.cmd/nl/nl.ex fails to account for line number truncation
    Problem Text Assertion 1042 runs the command



    printf 'one\ntwo\n' | $cmd -b a -v 0 -i 2147483647 > $CT_STDOUT 2> $CT_STDERR



    in order to generate a line-numbered file where the increment in line numbers is 2147483647. It then
    searches the output for the second line of the file, expecting to find the line "two" with the line number
    2147483647. But according to the specification at
    https://pubs.opengroup.org/onlinepubs/009695399/utilities/nl.html the default width for line numbers
    is 6, and to get a greater width you must use the option -w:



    "-w width

    Specify the number of characters to be used for the line number. The default width shall be 6."



    Our implementation places "483647 two" in the standard output, which in our understanding agrees
    with the requirements of the standard.



    A similar issue occurs with the second test in tp1042(), where the command



    printf 'one\n' | $cmd -b a -v 2147483647 > $CT_STDOUT 2> $CT_STDERR



    is issued, instructing nl to start numbering with 2147483647. The expected output does not use the
    truncated version of the line number. Our implementation writes "483647 one" to stdout, and again
    we think that this conforms to the standard.


    Test Output 400|212 1042 1 21:35:53|IC Start

    200|212 42 21:35:53|TP Start

    520|212 42 85589 1 1|Assertion #1042 (A): GA23: Handling number ranges.

    520|212 42 85589 2 1|"^2147483647 two" wasn't found in standard output

    520|212 42 85589 2 2|"^2147483647 one" wasn't found in standard output

    220|212 42 1 21:35:53|FAIL

    410|212 1042 1 21:35:53|IC End

    Review Information

    Review Type TSMA Review
    Start Date 2021-12-14 08:32
    Last Updated 2021-12-14 09:43
    Completed 2021-12-14 09:43
    Status Complete
    Review Recommendation Rejected (REJ)
    Review Response The output expected by the test is correct, as the standard does not
    permit nl to truncate line numbers.

    The STDOUT section of the nl page states that the format used for the
    line number is %6d. The 6 here specifies the _minimum_ field width, as
    stated in XBD chapter 5.

    When the line number 2147483647 is formatted with %6d the result, just as
    for printf, is required to be 2147483647.

    It is recommended that this request is rejected.

    Review Type SA Review
    Start Date 2021-12-14 17:43
    Last Updated 2021-12-14 14:19
    Completed 2021-12-14 14:19
    Status Complete
    Review Resolution Rejected (REJ)
    Review Conclusion This request is rejected.

    The output expected by the test is correct, as the standard does not
    permit nl to truncate line numbers.

    The STDOUT section of the nl page states that the format used for the
    line number is %6d. The 6 here specifies the _minimum_ field width, as
    stated in XBD chapter 5.

    When the line number 2147483647 is formatted with %6d the result, just as
    for printf, is required to be 2147483647.

    Problem Reporting System Options:

     

    Back   

Contact the Certification Authority