Paul Eggert wrote:
> It was more like this:
>
>#define _GL_NORETURN_FUNC_Noreturn __attribute_noreturn__
>#define _GL_NORETURN_FUNCPTR __attribute_noreturn__
Per [1] (compare fptr33 and fptr34), this has identical effects as
#define _GL_NORETURN_FUNC__attribute_noreturn__
#
On 04/28/2017 09:40 AM, Bruno Haible wrote:
You have been thinking of this?
#define _GL_NORETURN_FUNC_Noreturn
#define _GL_NORETURN_FUNCPTR _Noreturn __attribute__ ((__noreturn__))
It was more like this:
#define _GL_NORETURN_FUNC_Noreturn __attribute_noreturn__
#define _GL_NO
> You have been thinking of this?
> #define _GL_NORETURN_FUNC_Noreturn
> #define _GL_NORETURN_FUNCPTR _Noreturn __attribute__ ((__noreturn__))
This approach does not work:
===
void func1 (void) { for (;;); }
_Nore
Hi Paul,
> I thought we had established that in some cases one should apply both
> _Noreturn and __attribute__ ((__noreturn__)) to the same declaration? I
> don't see that in this module.
Apparently we've been thinking at different solutions of the clang problem
(which, for type checking / assi
I thought we had established that in some cases one should apply both
_Noreturn and __attribute__ ((__noreturn__)) to the same declaration? I
don't see that in this module.
Also, I hope we're not envisioning a lot of replacement of _Noreturn
with _GL_NORETURN_FUNC in other modules. As I unders
Here's a proposed module 'noreturn' (attached).
The most interesting file is this one:
lib/noreturn.h
/* Macros for declaring functions as non-returning.
Copyright (C) 2017 Free Software Foundation, Inc.
This program is free
