Bug 28632 - 'strings --help' talks about zero-terminated strings
Summary: 'strings --help' talks about zero-terminated strings
Status: RESOLVED FIXED
Alias: None
Product: binutils
Classification: Unclassified
Component: binutils (show other bugs)
Version: 2.37
: P2 minor
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-11-28 17:40 UTC by Georg Brandl
Modified: 2021-11-29 15:39 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Georg Brandl 2021-11-28 17:40:29 UTC
The --help output of strings (version 2.37) says:

  -n --bytes=[number]       Locate & print any NUL-terminated sequence of at
  -<number>                   least [number] characters (default 4).

However, the info-page states correctly:

   For each FILE given, GNU 'strings' prints the printable character
   sequences that are at least 4 characters long (or the number given with
   the options below) and are followed by an unprintable character.

(and later)

   '-MIN-LEN'
   '-n MIN-LEN'
   '--bytes=MIN-LEN'
        Print sequences of characters that are at least MIN-LEN characters
        long, instead of the default 4.

which does not imply NUL termination, and I also don't see NUL termination being a requirement for 'strings' recognizing strings.


PS: in the comment at the top of strings.c, even another version can be found:

   --bytes=min-len
   -n min-len
   -min-len Print graphic char sequences, MIN-LEN or more bytes long,
        that are followed by a NUL or a newline.  Default is 4.
Comment 1 cvs-commit@gcc.gnu.org 2021-11-29 14:53:05 UTC
The master branch has been updated by Nick Clifton <nickc@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=8fee99c3c8e25f2708bddde345c192dd2f3e7e08

commit 8fee99c3c8e25f2708bddde345c192dd2f3e7e08
Author: Nick Clifton <nickc@redhat.com>
Date:   Mon Nov 29 14:52:42 2021 +0000

    Update description of string's -n option.
    
            PR 28632
            * strings.c (usage): Update desciption of -n option.
            * doc/binutils.texi: Likewise.
Comment 2 Nick Clifton 2021-11-29 14:55:48 UTC
Hi Georg,

  Thanks for raising this issue.

  I have checked in a patch which changes the --help output to read:

  -n <number>               Locate & print any sequence of at least <number>
    --bytes=<number>         displayable characters.  (The default is 4).

  And I have updated the description in binutils.texi so that it goes
  into a bit more detail:

    Print sequences of displayable characters that are at least
    <min-len> characters long.  If not specified a default minimum
    length of 4 is used.  The distinction between displayable and
    non-displayable characters depends upon the setting of the 
    -e and -U options.  Sequences are always terminated at control 
    characters such as new-line and carriage-return, but not
    the tab character.

Cheers
  Nick
Comment 3 Georg Brandl 2021-11-29 15:25:21 UTC
Great, thanks!  While checking it out (-U was new to me), I noticed that in the --help string and the comment at the top of strings.c it is referred to as (lowercase) -u - maybe you can fix this as well.
Comment 4 cvs-commit@gcc.gnu.org 2021-11-29 15:38:15 UTC
The master branch has been updated by Nick Clifton <nickc@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=584294c4066d0101161e4e04744a46cce7a7863e

commit 584294c4066d0101161e4e04744a46cce7a7863e
Author: Nick Clifton <nickc@redhat.com>
Date:   Mon Nov 29 15:37:24 2021 +0000

    strings: Replace references to -u option with references to -U.
    
            PR 28632
Comment 5 Nick Clifton 2021-11-29 15:39:00 UTC
(In reply to Georg Brandl from comment #3)
> Great, thanks!  While checking it out (-U was new to me), 

It is a brand new option... :-)

> I noticed that in
> the --help string and the comment at the top of strings.c it is referred to
> as (lowercase) -u - maybe you can fix this as well.

Done.