[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Merging feature/android
From: |
Po Lu |
Subject: |
Re: Merging feature/android |
Date: |
Mon, 06 Mar 2023 21:10:46 +0800 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Arsen Arsenović <arsen@aarsen.me> writes:
> Po Lu <luangruo@yahoo.com> writes:
>
>> Arsen Arsenović <arsen@aarsen.me> writes:
>>
>>> Depending on how long ago that was, it might be worth reconsidering.
>>> GCC has been C++ for a decade now, for instance, so C++ compilers are
>>> likely fairly widespread. One could make the case that using portable
>>> C++ in addition to portable C is a more portable way to do cleanups than
>>> GNU C cleanups.
>>>
>>> If still undesirable, I strongly suggest at least using GNU C cleanups.
>>> They are a decent workaround.
>>
>> GNU C cleanups only work when compiling with -fexceptions.
>
> This is not the case. They work under all conditions, and are used to
> great effect in many C codebases. As an example, the following:
>
> int
> f (void (*foo) (void))
> {
> __attribute__ ((cleanup (test))) int* n = g ();
> foo ();
> }
>
> ... generates:
>
> f:
> pushq %rbx
> xorl %eax, %eax
> movq %rdi, %rbx
> subq $16, %rsp
> call g
> movq %rax, 8(%rsp)
> call *%rbx
> leaq 8(%rsp), %rdi
> call test /* cleanup */
> addq $16, %rsp
> popq %rbx
> ret
>
> ... with -O3 -fno-exceptions. The latter is the default for C, but I
> wanted to be explicit anyway.
I meant that they only work to handle C++ exceptions when you compile
with -fexceptions, so it is rather pointless to use it as we do now.
Without -fexceptions, that code is no different from:
f (foo)
int (*foo) ();
{
int *n;
n = g ();
foo ();
test (fn);
}
> It is likely as widely available as cleanup attributes. Certainly as
> widely as any supported (or many unsupported) versions of GCC are.
>
> I won't argue on the merits of the language, as that usually doesn't go
> anywhere, and the cleanup attribute seems like an accepted solution
> anyway. Note that it's no coincidence that it is being adopted by some
> GNU projects.
The GNU Coding Standards recommend against relying on GNU C extensions
in Emacs.
> I agree that it isn't necessary. I was just answering the question of
> what '-fexceptions' would do as someone with the know-how, because it
> was brought up.
OK, then let's not waste any more time here. Thanks.
- Re: __attribute__ ((cleanup)) and emacs-module.c, (continued)
- Re: __attribute__ ((cleanup)) and emacs-module.c, Po Lu, 2023/03/09
- Re: __attribute__ ((cleanup)) and emacs-module.c, Paul Eggert, 2023/03/10
- Re: __attribute__ ((cleanup)) and emacs-module.c, Po Lu, 2023/03/10
- Re: __attribute__ ((cleanup)) and emacs-module.c, Paul Eggert, 2023/03/11
- Re: __attribute__ ((cleanup)) and emacs-module.c, Po Lu, 2023/03/11
- Re: __attribute__ ((cleanup)) and emacs-module.c, Paul Eggert, 2023/03/11
- Re: Merging feature/android, Eli Zaretskii, 2023/03/08
- Re: Merging feature/android, Arsen Arsenović, 2023/03/06
- Re: Merging feature/android, Po Lu, 2023/03/06
- Re: Merging feature/android, Arsen Arsenović, 2023/03/06
- Re: Merging feature/android,
Po Lu <=
- Re: Merging feature/android, Eli Zaretskii, 2023/03/05
- Re: Merging feature/android, Po Lu, 2023/03/05
- Re: Merging feature/android, Richard Stallman, 2023/03/04
- Re: Merging feature/android, Po Lu, 2023/03/05
- Re: Merging feature/android, Richard Stallman, 2023/03/06
- Re: Merging feature/android, Po Lu, 2023/03/06
- Re: Merging feature/android, Paul Eggert, 2023/03/03
- Re: Merging feature/android, Po Lu, 2023/03/03
- Re: Merging feature/android, Eli Zaretskii, 2023/03/04
- Re: Merging feature/android, Po Lu, 2023/03/04