Jeff Law writes:
> On 7/9/24 7:12 AM, Christoph Müllner wrote:
>> On Tue, Jul 9, 2024 at 3:01 PM Kito Cheng wrote:
>>>
>>> IIRC Jeff mentions that it may introduce buffer overflow if the input
>>> string is long enough.
>>
>> The manpage states:
>>If the allocation causes stack overflow,
On 7/9/24 7:12 AM, Christoph Müllner wrote:
On Tue, Jul 9, 2024 at 3:01 PM Kito Cheng wrote:
IIRC Jeff mentions that it may introduce buffer overflow if the input
string is long enough.
The manpage states:
If the allocation causes stack overflow, program behavior is undefined.
This
On Tue, Jul 9, 2024 at 3:01 PM Kito Cheng wrote:
>
> IIRC Jeff mentions that it may introduce buffer overflow if the input
> string is long enough.
The manpage states:
If the allocation causes stack overflow, program behavior is undefined.
This was considered reasonable for AArch64:
IIRC Jeff mentions that it may introduce buffer overflow if the input
string is long enough.
On Tue, Jul 9, 2024 at 8:48 PM Christoph Müllner
wrote:
>
> Allocating an object on the heap with new, wrapping it in a
> std::unique_ptr and finally getting the buffer via buf.get()
> is a correct way
Allocating an object on the heap with new, wrapping it in a
std::unique_ptr and finally getting the buffer via buf.get()
is a correct way to allocate a buffer that is automatically
freed on return. However, a simple invocation of alloca()
does the same with less overhead.
gcc/ChangeLog:
