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_NORETU
I wrote:
> I guess I need to test things with some older versions of gcc and g++ as well,
> and with MSVC, before we can jump to conclusions.
Here are the results. Let 1, 2, 3, 4, 5 denote the respective positions:
XX extern void foo1 (void);
extern XX void foo2 (void);
extern void XX foo3 (void);
Bruno Haible wrote:
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 w
Hi Paul,
> > If we want to offer a short macro name, such as _GL_NORETURN, it should
> > be usable in both places, function declarations and function pointers.
> > That is, make it an alias of _GL_NORETURN_FUNCPTR.
> ...
> Function pointers are relatively rare compared to function definitions
> a
On 04/24/2017 01:38 PM, Bruno Haible wrote:
Hi Paul,
the only position that works for both C and C++ is the first one:
_GL_NORETURN_FUNC extern void foo (void);
Maybe a shorter name for this usage: _GL_NORETURN, perhaps?
If we want to offer a short macro name, such as _GL_NORETURN, it sho
Hi Paul,
> > the only position that works for both C and C++ is the first one:
> >_GL_NORETURN_FUNC extern void foo (void);
>
> Maybe a shorter name for this usage: _GL_NORETURN, perhaps?
If we want to offer a short macro name, such as _GL_NORETURN, it should
be usable in both places, functi
On 04/23/2017 01:58 PM, Bruno Haible wrote:
the only position that works for both C and C++ is the first one:
_GL_NORETURN_FUNC extern void foo (void);
Maybe a shorter name for this usage: _GL_NORETURN, perhaps?
Don't some compilers complain if the storage class ('extern', here) is
not fir
Hi Paul,
> Although this will work for GCC and Clang, I suppose it might cause other
> compilers to generate slightly-less-efficient code, because they won't know
> that
> print_and_abort does not return.
Good point. Yes.
> To avoid that problem, how about this further patch?
Yes, this fits
Bruno Haible wrote:
1) If _Noreturn does not apply to function pointers, only to functions, we
should better avoid it. It's an ill-defined standard's feature.
Hmm, well, we cannot avoid _Noreturn in general, since the standard requires it
for functions defined by the standard. Admittedly t
Hi Paul,
Thanks for explaining.
> > What is the semantic difference between _Noreturn and
> > __attribute_noreturn__?
>
> __attribute__ ((__noreturn__)), which the latter expands to, also works with
> function pointers, whereas _Noreturn does not. The distinction can matter
> when a
> functio
Bruno Haible wrote:
What is the semantic difference between _Noreturn and
__attribute_noreturn__?
__attribute__ ((__noreturn__)), which the latter expands to, also works with
function pointers, whereas _Noreturn does not. The distinction can matter when a
function's address is assigned to a f
On Mac OS X 10.12 (with gcc -> clang), with CPPFLAGS=-Wall, I get this
warning:
obstack.c:351:31: warning: incompatible pointer types initializing 'void
(*)(void) __attribute__((noreturn))' with an expression of type 'void (void)'
[-Wincompatible-pointer-types]
__attribute_noreturn__ void (*obst
12 matches
Mail list logo
