This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Should malloc-related functions be weak?
- From: "Tulio Magno Quites Machado Filho" <tuliom at linux dot vnet dot ibm dot com>
- To: Florian Weimer <fweimer at redhat dot com>, Libc-alpha Mailing List <libc-alpha at sourceware dot org>
- Cc:
- Date: Fri, 29 Jul 2016 16:11:56 -0300
- Subject: Re: Should malloc-related functions be weak?
- Authentication-results: sourceware.org; auth=none
- References: <87eg6cuwp7.fsf@totoro.br.ibm.com> <5af377a6-4b96-b339-019d-f56c2fca2ca2@redhat.com>
Florian Weimer <fweimer@redhat.com> writes:
> On 07/29/2016 02:27 PM, Tulio Magno Quites Machado Filho wrote:
>>
>> According to the __malloc_hook man page [1]
>>
>> Programmers should instead preempt calls to the relevant functions by
>> defining and exporting functions such as "malloc" and "free".
>>
>> But malloc, free and realloc are all global functions, causing problems when
>> linking statically.
>>
>> Shouldn't they be weak functions?
>
> I don't think so. With those non-weak definition, the static linker
> enforces that you interpose *all* malloc-related APIs in use.
Including the new __malloc_fork_lock_parent, __malloc_fork_unlock_parent and
__malloc_fork_unlock_child?
--
Tulio Magno