This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] malloc: Use compat_symbol_reference in libmcheck [BZ #22050]


On 08/31/2017 06:08 PM, Carlos O'Donell wrote:
On 08/31/2017 11:04 AM, Joseph Myers wrote:
On Thu, 31 Aug 2017, Florian Weimer wrote:

On 08/31/2017 05:42 PM, Zack Weinberg wrote:
On Thu, Aug 31, 2017 at 11:37 AM, Carlos O'Donell <carlos@redhat.com> wrote:
I would like to see a new macro that does what it says, rather than use the
existing macro in the wrong way. Even if the new macro is just a copy.

This looks like a real problem for glibc, particularly if we need to continue
to use, at least internally, certain old versions of symbols. So having a
new macro for this is fine.

I see immediate uses for this macro in the test suite, verifying that
compat symbols continue to work correctly...  (particularly thinking
of the messy and totally untested old-FILE support).

That's the exact purpose of compat_symbol_reference.  I think Carlos is
objecting to its use for a *definition*.

Well, I used it for the definitions of matherr and _LIB_VERSION in my
tests of those compat symbols, because it does exactly what's expected:
makes the definitions in the tests refer to the same entity as the compat
symbols in the shared libraries, rather than being completely independent
entities as they would by default.
While it does what's expected, the macro API wasn't designed with that in
mind was it?

I would have used it in tst-mallocstate for __malloc_initialize_hook if I had understood what was going on. I think the usages are so similar that we do not need a new macro.

Thanks,
Florian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]