OS: Archlinux x86_64, valgrind 3.12, glibc 2.24

I'm not sure whether this has been previously reported, but with the change to printf in glibc 2.23, valgrind now reports 1024 bytes allocated when printf (or any of the printf family of function) are used. (It was explained to me as being related to the following mmap to malloc change: https://sourceware.org/bugzilla/show_bug.cgi?id=16734) This results in the unexpected reporting of memory allocated, where before the same code would report none. Example:

#include <stdio.h>

int main (int argc, char **argv) {

    char *s = argc > 1 ? argv[1] : "hello valgrind";
    printf ("%s\n", s);
    return 0;
}

Expected Heap Summary:

$ valgrind ./bin/hello
==9626== Memcheck, a memory error detector
==9626== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==9626== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==9626== Command: ./bin/hello
<snip>
total heap usage: 0 allocs, 0 frees, 0 bytes allocated

Actual Heap Summary:

$ valgrind ./hello
==18061== Memcheck, a memory error detector
==18061== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==18061== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==18061== Command: ./hello
<snip>
total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated

I don't know whether a new exclusion needs to be written or what, but I cannot see this being expected behavior from valgrind.