malloc: performance improvements and bugfixes

[Paul Eggert]

On 01/26/2016 02:24 PM, Florian Weimer wrote:
> But this file does not use any of the deprecated (or
> soon-to-be-deprecated) identifiers.
>
> The deprecation warnings I'm talking about are not #warning directives
> in the header file.  You only get them if you use the very identifiers
> annotated with deprecation warnings (or if you use a preprocessor macro
> that is subject to a warning hack).

Thanks, I see now. However, GCC does not issue the deprecation warning 
even if the hook is used, so long as the hook is initialized the way 
that Emacs does it. (Emacs must initialize the hook statically because 
the initialization must take effect before 'main' is called.) So, for 
example, if I compile the attached program on Fedora 23 with GCC, the 
program compiles and runs without complaint.

The failure to warn is arguably a GCC bug. It's a blessing in disguise 
for Emacs, as I don't want the deprecation warning there anyway.

I plan to install something into Emacs that includes <malloc.h> before 
initializing the hook, though, as that's just standard hygiene. Perhaps 
some day GCC will issue the warning you want....

-------------- next part --------------
#include <unistd.h>
#include <malloc.h>

#ifndef __MALLOC_HOOK_VOLATILE
# define __MALLOC_HOOK_VOLATILE
#endif

static int foo = 1;

static void
malloc_initialize_hook (void)
{
  foo = 0;
}

void (*__MALLOC_HOOK_VOLATILE __malloc_initialize_hook) (void)
  = malloc_initialize_hook;

int
main (void)
{
  char *p = malloc (100);
  read (-1, p, 100);
  free (p);
  return foo;
}