On 2026/09/05 11:03, Kirill Makurin wrote:
> Zhongteng Gui <[email protected]> wrote:
> 
>> 1. Originally, we provide `int gettimeofday(struct timeval*, void*)`, while
>> POSIX expects `int gettimeofday(struct timeval*, struct timezone*)`. It's
>> noteworthy that switching to POSIX will breaks GCC without special handling.
>> because libiberty.h bundled by GCC specially checked for __MINGW32__, and
>> declares gettimeofday with `void*` arg type, which fails with
>> -Wstrict-prototypes. But keeping `void*` is semantically wrong, as we 
>> actually
>> set timezone if nonnull.
> 
> Are you sure? 2018 edition of POSIX specification[1] declares it as `int 
> gettimeofday(struct timeval *restrict tp, void *restrict tzp)`.
> 
> It also says:
> 
> ```
> If tzp is not a null pointer, the behavior is unspecified.
> ```
> 
> And so, POSIX says nothing about `struct timezone`, what it is and how to use 
> it.

I got the impression from
https://www.man7.org/linux/man-pages/man2/gettimeofday.2.html

Seemes that POSIX uses `void*`, while glibc uses `struct timezone*`.

> 
>> 2. Should we conditionally expose gettimeofday? It is marked as obsolete in
>> POSIX.1-2008 and removed in POSIX.1-2024.
> 
> I see no reason to do this; I think this would an unnecessary complication. 
> Maybe `attribute((deprecated))` is an option, but IMO, it creates more 
> annoyance than benefits.
> 
>> 3. Originally, gettimeofday assumed "struct timeval*" to be nonnull, and 
>> didn't
>> check this. Should we keep this as is, or check it and return -1 if NULL?
> 
> I have a few changes to `pthread_mutex_timedlock` in my winpthreads mutex 
> changes I sent to the list, and POSIX does not say anything about `struct 
> timespec` argument being NULL. So, for both cases, my assumption here is that 
> NULL is not a valid value for the parameter, and application must never pass 
> it, and so checking for it is unnecessary.
> 
> - Kirill Makurin
> 
> [1] 
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/gettimeofday.html
> 



_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to