[PATCH] check_native: Get rid of alloca
Adhemerval Zanella Netto
adhemerval.zanella@linaro.org
Thu Jun 1 11:30:24 GMT 2023
On 01/06/23 06:07, Florian Weimer wrote:
> * Andreas Schwab:
>
>> On Jun 01 2023, Florian Weimer wrote:
>>
>>> The current code does handle cancellation. Isn't sendto a cancellation
>>> point?
>>
>> Cancellation depends on unwinding.
>
> Sorry, I meant to write “does NOT handle cancellation”.
>
>>> In any case, we'd have to build with -fexceptions to turn the destructor
>>> into a cancellation handler, not -fasynchronous-unwind-tables.
>>
>> -fexceptions does not enable asynchronous unwinding.
>
> But the unwinding is synchronous if it is triggered from a cancellation
> point because on the caller side, it looks like we are unwinding through
> a regular function call which is not _THROW.
>
> Using malloc will never be async-cancel-safe.
>
> Anyway, if we use __attribute__ ((cleanup)) to write cancellation
> handlers (as opposed to mere destructors), that definitely is worthy of
> discussion.
Fair enough, I think there is no urgent need to use __attribute__ ((cleanup)),
although it does simplify some resource cleanup.
Should we remove the one use on sysdeps/posix/readv.c and sysdeps/posix/writev.c?
It is only used on Hurd (which I am not use if support cancellation), but it
a precedent to other developers that __attribute__ ((cleanup)) might be used
in other code.
More information about the Libc-alpha
mailing list