This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/86013] std::vector::shrink_to_fit() could sometimes use realloc()
- From: "jan.kratochvil at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 06 Jun 2018 14:33:37 +0000
- Subject: [Bug libstdc++/86013] std::vector::shrink_to_fit() could sometimes use realloc()
- Auto-submitted: auto-generated
- References: <bug-86013-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86013
--- Comment #11 from Jan Kratochvil <jan.kratochvil at redhat dot com> ---
(In reply to Jonathan Wakely from comment #10)
> Does your &n!=&alias##n check still work if operator new is replaced in a
> different translation unit, but the default one is the only one in scope in
> the current TU?
alias##n is expected to be a visibility-hidden symbol of libstdc++ so there
will be no ld.so relocation.
n will be relocated by ld.so as R_X86_64_GLOB_DAT to the real function wherever
it comes from in the final process. It will not point to the PLT slot of
libstdc++.
ISO C++ does not specify the replacement specifics, they say only "displaces
the default version defined by the C ++ standard library".
Here they talk about them:
http://en.cppreference.com/w/cpp/memory/new/operator_new#Global_replacements
I expect replacing an allocator needs to be done globally for a process as one
may pass allocated objects ownership between program/libraries. That is
typically from the main program or by LD_PRELOAD. Although cppreference talks
about visibility so I guess they think replacing 'operator new' only in one ELF
image (program / shared library) with -fvisibility=hidden is also valid. They
talk about undefined behavior if the replacement is specific only to some TU
which I also find obvious.