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. > 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
