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: Should malloc-related functions be weak?

From: Florian Weimer <fweimer at redhat dot com>
To: Pedro Alves <palves at redhat dot com>, DJ Delorie <dj at redhat dot com>
Cc: Tulio Magno Quites Machado Filho <tuliom at linux dot vnet dot ibm dot com>, libc-alpha at sourceware dot org
Date: Mon, 1 Aug 2016 12:39:56 +0200
Subject: Re: Should malloc-related functions be weak?
Authentication-results: sourceware.org; auth=none
References: <87eg6cuwp7.fsf@totoro.br.ibm.com> <xnbn1ed1p8.fsf@greed.delorie.com> <87oa5d29xf.fsf@mid.deneb.enyo.de> <7514658e-ead9-1c3e-5fa2-5a6afc9cb54f@redhat.com>

On 08/01/2016 12:25 PM, Pedro Alves wrote:

On 07/31/2016 02:50 PM, Florian Weimer wrote:

* DJ Delorie:

"Tulio Magno Quites Machado Filho" <tuliom@linux.vnet.ibm.com> writes:

Shouldn't they be weak functions?


I can imagine the mess that would happen if someone overwrode malloc()
but not free()...


The problem is with the other symbols Tulio identified.  I'll try to
see if providing weak stubs for them addresses the issue.


Are these other symbols meant be overridden?

These symbols (__malloc_fork_lock_parent etc.) are not supposed to beoverridden, they are entirely internal to glibc and its mallocimplementation. If the glibc malloc is interposed, these functionsshould not do anything.


Thanks,
Florian

Follow-Ups:
- Re: Should malloc-related functions be weak?
  - From: Pedro Alves

References:
- Re: Should malloc-related functions be weak?
  - From: Pedro Alves

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