[Bug binutils/29707] binutils c++filt reads a file with the first character \x00, it will wait for input and cause the program to block.

[fengzhengzhan at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=29707

--- Comment #2 from 烽征战 <fengzhengzhan at gmail dot com> ---
Thanks for your patience!

nickc at redhat dot com <sourceware-bugzilla@sourceware.org> 于2022年10月21日周五
18:35写道：

> https://sourceware.org/bugzilla/show_bug.cgi?id=29707
>
> Nick Clifton <nickc at redhat dot com> changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>          Resolution|---                         |NOTABUG
>              Status|UNCONFIRMED                 |RESOLVED
>                  CC|                            |nickc at redhat dot com
>
> --- Comment #1 from Nick Clifton <nickc at redhat dot com> ---
> Hi,
>
>   This is not a bug, it is expected behaviour.
>
>   c++filt has two modes of operation.  If it is given strings on its
> command
>   line then it decodes them one at a time and then exits.  If it is not
>   given any strings to decode then it reads from the standard input stream
>   and decodes each line until it sees an end-of-file marker.
>
>   Command line options do not count as strings to decode, so running
>   "c++filt --types" for example will still cause the program to read from
>   the standard input.  In addition c++file supports the @-file syntax,
>   allowing command line options and strings to decode to be placed into a
>   file and then passed to c++filt via a command line option of
> @<name-of-file>.
>
>   So in your test case, running: "c++filt @c++filt/crash01_timeout" causes
>   the contents of c++filt/crash01_timeout to be read and processed.  Since
>   the file is expected to contain text, not binary, any nul character
> (\x00)
>   is treated as an end-of-file marker, and processing will stop at that
>   character.
>
>   Hence when the first character of c++filt/crash01_timeout is a nul
> character
>   the entire file is treated as if it were empty, and the logic in c++filt
>   sees that no strings were provided on the command line, and hence it
> starts
>   to read from stdin, waiting for the user to provide input to decode.
>
>   When the first character of c++filt/crash01_timeout is not a nul
> character
>   the file is treated as having some contents which are passed back to
> c++filt
>   to decode, and so once that is done c++filt terminates.
>
> Cheers
>   Nick
>
> --
> You are receiving this mail because:
> You reported the bug.

-- 
You are receiving this mail because:
You are on the CC list for the bug.