[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] stdnoreturn: new module
From: |
Paul Eggert |
Subject: |
Re: [PATCH] stdnoreturn: new module |
Date: |
Tue, 28 Feb 2012 15:11:00 -0800 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1 |
On 02/28/2012 04:55 AM, Eric Blake wrote:
> The trick is that on MSVC, we have to define noreturn in terms of
> itself, so that pre-processing doesn't recursively expand things, then
> _Noreturn is defined in terms of noreturn.
But the problem isn't <stdnoreturn.h>; it's <stdlib.h>
when it's included after <stdnoreturn.h>. For example:
$ cat foo.c
/* contents of stdnoreturn.h */
#define noreturn __declspec(noreturn)
#define _Noreturn noreturn
/* contents of stdlib.h */
__declspec(noreturn) void abort (void);
$ gcc -E foo.c | tail -n1
__declspec(__declspec(noreturn)) void abort (void);
I thought about it some more, and came up with
one somewhat-extreme way to try to fix things.
<stdnoreturn.h> could do this:
#if 1200 <= _MSC_VER
# define noreturn
#else
# define noreturn _Noreturn
#endif
As I understand it, this would cause MSVC's stdlib.h to
expand to this:
__declspec( ) void abort (void);
which (if Microsoft's grammar is right) should compile.
This would mean MSVC would be like any random compiler,
where 'noreturn' has no effect on the compiler.
- [PATCH] stdnoreturn: new module, Paul Eggert, 2012/02/24
- Re: [PATCH] stdnoreturn: new module, Bruno Haible, 2012/02/27
- Re: [PATCH] stdnoreturn: new module, Bruno Haible, 2012/02/28
- Re: [PATCH] stdnoreturn: new module, Paul Eggert, 2012/02/28
- Re: [PATCH] stdnoreturn: new module, Eric Blake, 2012/02/28
- Re: [PATCH] stdnoreturn: new module, Bruno Haible, 2012/02/28
- Re: [PATCH] stdnoreturn: new module, Paul Eggert, 2012/02/29