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

[Jose Fonseca]

On 07/03/15 19:38, Emil Velikov wrote:
> On 07/03/15 07:23, Jose Fonseca wrote:
> ...
>> we still
>> didn't eliminate the use of non-portable _MTX_INITIALIZER_NP from Mesa
>> tree gave me pause.
>>
> The only way I can think about resolving this, is to use call_once() to
> initialize the mutex,

Yes, I'm afraid so.

Static initialization of is much simpler than the call_once paradigm, 
but unfortunately ISO didn't standardize a static initializer for ISO 
C11 threads.h, and we can't tell whether it will be possible to somehow 
to provide _MTX_INITIALIZER_NP on top of future C11 threads.h 
implementations that we might care about.

In particular, it is possible that GLIBC's C11 threads.h implementation 
of mutex will not be just a wrapper around pthreads:

  https://sourceware.org/ml/libc-alpha/2014-02/msg00782.html
  https://sourceware.org/bugzilla/show_bug.cgi?id=14092

And if mutexes become opaque binary structures, then it will really be 
impossible.

Maybe that's why ISO didn't do it -- precisely so that C11 mutexes 
internal representation doesn't need to be part of the ABI, only its 
size is, and standard lib is free to change its internals, withing that 
size.

> but I'm not 100% sure if T2 will sync until T1
> call_once's func has returned. How does it sound ?

I believe those are precisely the semantics of call_once.

>
> ...
>> 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).
>
> I have no objection on moving the file, but please keep the file name in
> some form that makes it obvious about the spec compat/wrapping it provides.
>
> FYI I'm contemplating on about adding a final wrapper - c99_string.h. It
> should nuke nearly all of the remaining compiler abstraction that we
> have around - mapi, egl, gallium, mesa, glsl...
>
> -Emil
>

Sounds good to me.  I can build-test them if Brian's not available.


I wonder if we should remove src/gallium/auxiliary/util/u_snprintf.c too.

This implementation of snprintf was necessary when we needed to build 
gallium for XP kernel mode, which didn't support floating-point support, 
but nowadays MSVC's _snprintf suits just as well AFAICT.


On the other hand, we should be careful about localization, as using the 
system's snprintf might easily cause floating/integers to formatted 
weirdly (extra spaces, commas, or different decimal separators. etc), so 
it's not safe to use it for things beyond user messages/logs...

That is, it might be better to override

   #define snprintf _unlocalized_snprintf
   #define asprintf _unlocalized_asprintf
   [...]

and provide our own implementations of all these...


Jose