On Mon, 3 May 2021, Christian Franke wrote:
Liu Hao wrote:
在 2021-05-03 14:49, Martin Storsjö 写道:
Just for the record - I wouldn't mind applying the patch or something like
it. I agree with the arguments that it would be beneficial to get more
precision here, even if one in general maybe can argue that we don't
strictly need to provide such precision.
Oh fair enough, if you would like it, I don't mind applying it either.
Attached is a new patch with '_Atomic' and 'intptr_t' as requested.
This version actually fails to compile with clang, with errors like these:
../misc/gettimeofday.c:45:74: error: initializer element is not a
compile-time constant
static _Atomic GetSystemTimeAsFileTime_t GetSystemTimeAsFileTime_p =
NULL;
^~~~
/home/martin/clang-trunk/i686-w64-mingw32/include/time.h:91:14: note:
expanded from macro 'NULL'
#define NULL ((void *)0)
^~~~~~~~~~~
It seems like it's impossible to provide an initializer to an _Atomic
variable with clang, if it's a function pointer type, while a regular
pointer can be initialized just fine that way.
If you'd leave out the "= NULL" it should be implicitly initialized to
zero as all static variables are, so that should be fine too.
But on the other hand, if we're using Interlocked* intrinsics for updating
it, we could just as well use an Interlocked* intrinsic for reading it
as well (for copying it over to a regular local variable), and then we
could do without the variable declared as _Atomic. (FWIW mingw-w64-crt
also builds with -std=gnu99, and _Atomic isn't guaranteed to exist until
C11 anyway, right?)
Also regarding the intptr_t cast, I think it'd be just as fine to cast it
directly to the desired destination type without taking it via an
intermediate intptr_t here - I see we do that in a number of other places.
// Martin
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
