[Mesa-dev] [PATCH 1/6] c11: add c11 compatibility wrapper around stdlib.h

[Jose Fonseca]

On 07/03/15 07:23, Jose Fonseca wrote:
> On 06/03/15 18:26, Brian Paul wrote:
>> On Fri, Mar 6, 2015 at 9:32 AM, Emil Velikov <emil.l.velikov at gmail.com
>> <mailto:emil.l.velikov at gmail.com>> wrote:
>>
>>     Used for aligned_alloc and other C11 functions missing from the
>> header.
>>
>>     Signed-off-by: Emil Velikov <emil.l.velikov at gmail.com
>>     <mailto:emil.l.velikov at gmail.com>>
>>     ---
>>       include/c11_stdlib.h | 118 ++++++++++++++++++++++++++++++
>>
>>
>> I wonder if this should be include/c11/stdlib.h instead.
>>
>> I also wonder if I should have put c99_math.h in c99/math.h  Jose
>> followed my pattern with c99_alloca.h
>>
>> We should probably be more consistent about this.  What do you think?
>
> No, {c11,c99}_foo.h are really different from {c11,c99}/foo.h
>
>
> include/c99 is added to the include path.  It is meant to have
> _complete_ header replacements (stdint.h, inttypes) for compilers that
> don't provide these C99 headers -- MSVC prior to 2013.  This way the C
> include can always just have
>
>    #include <stdint.h>
>
> regardless of the compiler.
>
> If c99_math.h is moved to c99/math.h then it will make it impossible to
> ever include the real MSVC's math.h whenever include/c99 is added to the
> path.
>
> This is also why c11/threads.h is in  c11.  It too is an complete
> implementation of C11'S threads.h.  And in fact we could just add
> include/c11 to the include path and drop the "c11/" prefix.  But the
> fact that GLIB started implement C11 threads.h, and because we still
> didn't eliminate the use of non-portable _MTX_INITIALIZER_NP from Mesa
> tree gave me pause.
>
>
> Now, things like c11_math.h c11_stdlib.h are a different beast --
> they're not complete replacement for the headers, but just wrappers
> around the headers which fixup missing things.  They can't ever be put
> in the include path.
>
>
> We can can consider move the c99_foo.h/c11_foo.h them somewhere else
> (another subdirectory, or util) or renaming them (like u_foo.h).  But
> the distinction between the stuff in c99/ and c11/ must be preserved
> somehow.

Oh nevermind this. Just saw your other reply.

Jose