[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: clang and _Noreturn
From: |
Bruno Haible |
Subject: |
Re: clang and _Noreturn |
Date: |
Wed, 26 Apr 2017 23:48:43 +0200 |
User-agent: |
KMail/5.1.3 (Linux/4.4.0-75-generic; KDE/5.18.0; x86_64; ; ) |
Hi Paul,
> > it's better ignore which
> > parts of the API will be used frequently or rarely. Better think only at
> > how easy it is to remember each item.
>
> Even if that's the criterion, I find it easier to remember "use _GL_NORETURN
> for
> most noreturn cases, and use _GL_ATTRIBUTE_NORETURN for when you want just
> the
> noreturn attribute" than to remember "use _GL_NORETURN_FUNC for most noreturn
> cases, and use _GL_NORETURN_FUNCPTR for when you want just the noreturn
> attribute".
I disagree again. The user should not need to know about whether the macros
expand to a keyword, an attribute, or whatever. That's part of their
implementation, which is meant to be opaque.
Seems we can't agree. Therefore I won't propose a short name '_GL_NORETURN'.
Bruno
- clang and _Noreturn, Bruno Haible, 2017/04/22
- Re: clang and _Noreturn, Paul Eggert, 2017/04/22
- Re: clang and _Noreturn, Bruno Haible, 2017/04/23
- Re: clang and _Noreturn, Paul Eggert, 2017/04/23
- Re: clang and _Noreturn, Bruno Haible, 2017/04/23
- Re: clang and _Noreturn, Paul Eggert, 2017/04/23
- Re: clang and _Noreturn, Bruno Haible, 2017/04/24
- Re: clang and _Noreturn, Paul Eggert, 2017/04/24
- Re: clang and _Noreturn, Bruno Haible, 2017/04/25
- Re: clang and _Noreturn, Paul Eggert, 2017/04/25
- Re: clang and _Noreturn,
Bruno Haible <=
- Re: clang and _Noreturn, Bruno Haible, 2017/04/26