public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Joseph Myers <joseph@codesourcery.com>
Cc: libc-alpha@sourceware.org
Subject: Re: [PATCH] malloc: Deprecate hook variables, __default_morecore, <mcheck.h>
Date: Tue, 15 Nov 2016 13:22:00 -0000	[thread overview]
Message-ID: <11f59117-e5a4-4c62-739c-e05e01ee43b3@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1610261548400.23075@digraph.polyomino.org.uk>

On 10/26/2016 05:55 PM, Joseph Myers wrote:
> On Wed, 26 Oct 2016, Florian Weimer wrote:
>
>> The functionality in <mcheck.h> will eventually be replaced with
>> no-op functions (and a separate, preloadable DSO).
>
> If you declare functionality deprecated then you need to update the manual
> accordingly.  But I don't think the right approach is to declare
> deprecated on an "eventually be replaced" basis.  Rather, the deprecation
> and the new DSO should be in the same patch series, going in the same
> glibc version, so the NEWS file and the main documentation can tell users
> of the mtrace script to preload the DSO and remove calls to the mtrace
> function (if that's the intended way to update code using mtrace and the
> one to be used for all the glibc tests that make use of it).

In my opinion, the larger ecosystem already provides suitable replacements.

* <mcheck.h> and all malloc hook functions are now deprecated.  Future
   implementations of the mcheck- and mtrace-related functions will not
   have any effect, and glibc will stop calling the hook functions from
   its malloc implementation.  Instead of mcheck and mtrace, developers
   should consider using valgrind.  As a replacement for the hook
   functions, developers can interpose their own malloc implementation.

Plus removal of the documentation of the hook functions from the manual 
(if there is anything left).

In any case, I'll submit a separate patch for documenting the malloc 
interposition feature (bug 20424).

Thanks,
Florian

  reply	other threads:[~2016-11-15 13:22 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-26 15:02 Florian Weimer
2016-10-26 15:55 ` Joseph Myers
2016-11-15 13:22   ` Florian Weimer [this message]
2016-11-15 15:39     ` Joseph Myers
2016-11-15 15:56       ` Florian Weimer
2016-11-16  1:37         ` Joseph Myers
2016-11-16  9:46           ` Will Newton
2016-11-17 13:00           ` Florian Weimer
2016-11-17 14:27             ` Joseph Myers
2016-11-17 14:50             ` Steve Vormwald
2016-11-17 16:08               ` Adhemerval Zanella
2016-11-18  9:13               ` Florian Weimer
2016-11-18 17:29                 ` Steve Vormwald
2016-11-21 19:43                   ` DJ Delorie
2016-11-22 15:12 ` Florian Weimer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=11f59117-e5a4-4c62-739c-e05e01ee43b3@redhat.com \
    --to=fweimer@redhat.com \
    --cc=joseph@codesourcery.com \
    --cc=libc-alpha@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).