Re: [PATCH] stdnoreturn: new module

2012-02-28 Thread Bruno Haible
Eric Blake wrote: > I'm leaning towards "#define noreturn /**/" as well. Me too. It's the most reliable, will not give us surprises. Bruno

Re: [PATCH] stdnoreturn: new module

2012-02-28 Thread Eric Blake
On 02/28/2012 05:38 PM, Paul Eggert wrote: > On 02/28/2012 04:01 PM, Bruno Haible wrote: >> But unfortunately there are also other possible elements in a declspec >> list, see [1]. I don't see how to accommodate these. > > [1] is for Visual Studio 2005; Visual Studio 2010 also has 'safebuffers' >

Re: [PATCH] stdnoreturn: new module

2012-02-28 Thread Paul Eggert
On 02/28/2012 04:01 PM, Bruno Haible wrote: > But unfortunately there are also other possible elements in a declspec > list, see [1]. I don't see how to accommodate these. [1] is for Visual Studio 2005; Visual Studio 2010 also has 'safebuffers'

Re: [PATCH] stdnoreturn: new module

2012-02-28 Thread Bruno Haible
Paul Eggert wrote: > I thought about it some more, and came up with > one somewhat-extreme way to try to fix things. > 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

Re: [PATCH] stdnoreturn: new module

2012-02-28 Thread Bruno Haible
Hi Paul, > > The current set of definitions > > > > #define _Noreturn __declspec (noreturn) > > #define noreturn _Noreturn > > > > leads to a syntax error when someone writes __declspec (noreturn), > > because preprocessing transforms it to __declspec (__declspec (noreturn)). > > > > How c

Re: [PATCH] stdnoreturn: new module

2012-02-28 Thread Paul Eggert
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 ; it's when it's included after . For example:

math: support for HUGE_VALF and HUGE_VALL

2012-02-28 Thread Bruno Haible
On some platforms, HUGE_VALF and HUGE_VALL are not defined. This fixes it. 2012-02-28 Bruno Haible math: Ensure HUGE_VAL, HUGE_VALF, HUGE_VALL are defined. * lib/math.in.h (HUGE_VAL, HUGE_VALF, HUGE_VALL): Define fallbacks. * tests/test-math.c: Include macros.h. Check

Re: docs: update glibc progress

2012-02-28 Thread Bruno Haible
Eric Blake wrote: > while the current POSIX 2008 (Issue 7) only > requires C99, the next POSIX 1x (Issue 8) will likely require C11. So I > think uchar.texi belongs under posix-headers, or else we create a new > intermediate directory for c11-headers and c11-functions. I don't think POSIX will di

Re: docs: update glibc progress

2012-02-28 Thread Eric Blake
On 02/28/2012 05:06 AM, Bruno Haible wrote: > Eric Blake wrote: >> Not listed: cygwin 1.7.10 added __fpurge, 1.7.11 added scandirat. >> Maybe it's worth creating pages under glibc-functions for those. > > You're right for scandirat. Done below. For __fpurge, I wouldn't mention > it since the prefi

Re: [PATCH] stdnoreturn: new module

2012-02-28 Thread Eric Blake
On 02/28/2012 01:45 AM, Paul Eggert wrote: > On 02/27/2012 06:29 PM, Bruno Haible wrote: >> The current set of definitions >> >> #define _Noreturn __declspec (noreturn) >> #define noreturn _Noreturn >> >> leads to a syntax error when someone writes __declspec (noreturn), >> because preprocessi

docs: update glibc progress

2012-02-28 Thread Bruno Haible
Eric Blake wrote: > Not listed: cygwin 1.7.10 added __fpurge, 1.7.11 added scandirat. > Maybe it's worth creating pages under glibc-functions for those. You're right for scandirat. Done below. For __fpurge, I wouldn't mention it since the prefix __ clearly means that it's not intended for direct u

Re: MSVC fails to compile floor.c with -fp:strict

2012-02-28 Thread Bruno Haible
Michael Goffioul wrote: > With the #pragma statement, the compilation error disappears, thanks. Thanks for verifying that we were on the right track. > I think the same > problem will appear in round.c and trunc.c (those are also used by > octave). Yes, and there are a few more. I'm applying thi

Re: [PATCH] stdnoreturn: new module

2012-02-28 Thread Paul Eggert
On 02/27/2012 06:29 PM, Bruno Haible wrote: > The current set of definitions > > #define _Noreturn __declspec (noreturn) > #define noreturn _Noreturn > > leads to a syntax error when someone writes __declspec (noreturn), > because preprocessing transforms it to __declspec (__declspec (noret