This is the mail archive of the
mailing list for the glibc project.
Re: RFC: __attribute_alloc_size__ on allocation functions (BZ#23741)
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: Carlos O'Donell <carlos at redhat dot com>, Zack Weinberg <zackw at panix dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 9 Nov 2018 19:42:23 -0200
- Subject: Re: RFC: __attribute_alloc_size__ on allocation functions (BZ#23741)
- References: <email@example.com> <CAKCAbMgXayegb1pFafYzfoh4ZXH2NYY_2URUehiPAH5=m9hbuQ@mail.gmail.com> <firstname.lastname@example.org>
On 09/11/2018 18:26, Carlos O'Donell wrote:
> On 11/9/18 10:36 AM, Zack Weinberg wrote:
>> On Fri, Nov 9, 2018 at 10:11 AM Adhemerval Zanella
>> <email@example.com> wrote:
>>> 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.
>> I think it makes sense to add the annotations and disallow allocations
>> larger than PTRDIFF_MAX for malloc and its family, but *not* for mmap,
>> brk, sbrk, and any other hypothetical system memory-allocation
>> primitives (IIRC Mach has something else) because those are not
>> necessarily used to allocate "objects" in the sense of the C standard,
>> and we know from other cases that people don't like it when glibc's
>> system call wrappers impose restrictions that the bare system call
> I tend to agree. I think the PTRDIFF_MAX limit for malloc only is OK.
> I wonder if we can't take advantage of that and gain some bits out
> of SIZE|AMP in the chunk header for other uses.
Not limiting allocation larger than PTRDIFF_MAX for mmap, brk, etc still
does not prevent the underlying issue of using the results as C object
(which is quite common). Also practically limiting such allocations only
really affects 32-bit.