diff options
author | Simon Marchi <simon.marchi@polymtl.ca> | 2020-07-02 20:38:47 -0400 |
---|---|---|
committer | Simon Marchi <simon.marchi@polymtl.ca> | 2020-07-03 22:27:09 -0400 |
commit | 14d960c82a6094551a0c463973b676136e4e60de (patch) | |
tree | efc7275422c30ffaa44a9de146f29b4e30174968 /gas/sb.c | |
parent | 211d5b1c18eb96459289e17b58e91fad46708173 (diff) | |
download | fsf-binutils-gdb-14d960c82a6094551a0c463973b676136e4e60de.zip fsf-binutils-gdb-14d960c82a6094551a0c463973b676136e4e60de.tar.gz fsf-binutils-gdb-14d960c82a6094551a0c463973b676136e4e60de.tar.bz2 |
gdb: make macro_expand_next return a gdb::unique_xmalloc_ptr<char>
For some reason, macro_expand_next does not return a
gdb::unique_xmalloc_ptr<char>, like its counterparts macro_expand and
macro_expand_once. This patch fixes that.
macro_buffer::release now returns a gdb::unique_xmalloc_ptr<char> too,
which required updating the other callers. The `.release (). release
()` in macro_stringify looks a bit funny, but it's because one release
is for the macro_buffer, and the other is for the unique ptr.
I removed the ATTRIBUTE_UNUSED_RESULT on macro_buffer::release, I don't
really understand why it's there. I don't see how this method could be
called without using the result, that would be an obvious memory leak.
The commit that introduced it (4e4a8b932b7 "Add ATTRIBUTE_UNUSED_RESULT
to macro_buffer") doesn't give any details.
gdb/ChangeLog:
* c-exp.y (scan_macro_expansion): Don't free `expansion`.
(lex_one_token): Update.
* macroexp.c (struct macro_buffer) <release>: Return
gdb::unique_xmalloc_ptr<char>.
(macro_stringify): Update.
(macro_expand): Update.
(macro_expand_next): Return gdb::unique_xmalloc_ptr<char>.
* macroexp.h (macro_expand_next): Likewise.
Change-Id: I67a74d0d479d2c20cdc82161ead7c54cea034f56
Diffstat (limited to 'gas/sb.c')
0 files changed, 0 insertions, 0 deletions