aboutsummaryrefslogtreecommitdiff
path: root/ld/NEWS
diff options
context:
space:
mode:
authorSimon Marchi <simon.marchi@polymtl.ca>2020-07-02 20:38:47 -0400
committerSimon Marchi <simon.marchi@polymtl.ca>2020-07-03 22:27:09 -0400
commit14d960c82a6094551a0c463973b676136e4e60de (patch)
treeefc7275422c30ffaa44a9de146f29b4e30174968 /ld/NEWS
parent211d5b1c18eb96459289e17b58e91fad46708173 (diff)
downloadgdb-14d960c82a6094551a0c463973b676136e4e60de.zip
gdb-14d960c82a6094551a0c463973b676136e4e60de.tar.gz
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 'ld/NEWS')
0 files changed, 0 insertions, 0 deletions