bin/46035: db(1) "-N" behaviour is reversed

[Alan Barrett <apb%cequrux.com@localhost>]

>Number:         46035
>Category:       bin
>Synopsis:       db(1) "-N" behaviour is reversed
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          doc-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Feb 17 08:25:00 +0000 2012
>Originator:     Alan Barrett
>Release:        NetBSD 5.99.65
>Organization:
Not much
>Environment:
System: NetBSD 5.99.65 i386
>Description:
        The db(1) man page says

           -N          Do not include the NUL byte at the end of the key or
                       value.

        but the actual behaviour is the reverse: The last byte in
        the key or value is suppressed by default (whether or not
        the last byte is a NUL), and the "-N" flag causes the last
        byte to be included.
>How-To-Repeat:
        $ db -Sb -Ub -To -N hash /etc/pwd.db 'VERSION'
        db: Unknown key `VERSION'
        $ db -Sb -Ub -To -N hash /etc/pwd.db 'VERSION\0'
        VERSION\000     \001\000\000\000
        $ db -Sb -Ub -To hash /etc/pwd.db 'VERSION'
        VERSION \001\000\000
        $ db -Sb -Ub -To hash /etc/pwd.db 'VERSION\0'
        db: Unknown key `VERSION\0'

        Clearly, the invocations with "-N" are displaying an extra
        byte on output, and parsing an extra byte on input, which
        is the reverse of the documented behaviour.

        In the source code, there's a flag named F_NO_NUL, but its
        use is the reverse of its name.  When the flag is set, the
        extra byte is NOT removed, and when the flag is not set,
        the extra byte IS removed.

>Fix:
        Change the documentation to match the behaviour.

        Change the source code to use an F_INCLUDE_NUL flag instead
        of F_NO_NUL, leaving the externally observable behaviour
        unchanged, but fixing the inconsistency between the name
        and the meaning of the flag.

        Alternatively, change the behaviour to match the documentation,
        but this would be an incompatible change, and will break
        almost all users of db(1).