This is the mail archive of the
libc-alpha@sourceware.org
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: <aa9e2a38-2dc3-11a9-711b-412b10260830@linaro.org> <CAKCAbMgXayegb1pFafYzfoh4ZXH2NYY_2URUehiPAH5=m9hbuQ@mail.gmail.com> <2540f0c3-a1bc-323b-3f21-af84bc919846@redhat.com>
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
>> <adhemerval.zanella@linaro.org> 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
>> doesn't.
>
> 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.