RFC: __attribute_alloc_size__ on allocation functions (BZ#23741)

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

BZ#23741 suggests glibc adds gcc __attribute_alloc_size__ on malloc functions
so asking allocation larger than PTRDIFF_MAX emits a warning that the value
exceeds maximum object size.

As I commented out, It has been discussed how to handle objects larger than 
PTRDIFF_MAX on GCC PR#67999 [1] and I think the issue is now glibc *does* allow 
such objects.

We do use the attribute on C11 aligned_alloc, but my guess is to enforce size is 
multiple than alignment instead of enforcing object size are no larger than
PTRDIFF_MAX.

It seems that some *very* specific programs do allocate objects larger PTRDIFF_MAX, 
as indicated by Florian in GCC PR#67999 (at least for 32 bits, since afaik currently
there is no architecture/os that supports that large VMA range).

But current GCC support for such objects is sketchy to say at least and others 
libc are moving to not allow it. GCC 7 and later will also diagnose such allocation 
and throw a warning, however, it won't be shown if the user disables builtins.

So I think before adding such annotation we need to discuss whether we want to allow 
such kind of allocation on malloc and mmap functions. To comparison:

  - bionic/musl: explicit disable object larger than PTRDIFF_MAX (ENOMEM is returned)
  
  - solaris11: both malloc and mmap do allow object larger than PTRDIFF_MAX, however
    kernels return ENOMEM for both 32 and 64 bit (malloc on 32 bit might indeed
    succeed because solaris11 malloc implementation seems to first try brk instead
    of mmap).

  - freebsd11: both malloc and mmap do allow object larget than PTRDIFF_MAX (although
    for 32-bit malloc returns NULL for PTRDIFF_MAX and PTRDIFF_MAX+1)

  - macosx: both malloc and mmap do allow object larget than PTRDIFF_MAX, although
    for malloc the system prints an error (mach_vm_map failed (error code=3)).