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 are on the CC list for the bug.
