Sevan Janiyan wrote: > I've not followed the project for a length of time and unfamiliar with > the coding style but I was wondering why did you opt to add a new case > specifically for Darwin, where the generic catchall could be to utilise > pthread_rwlock_init by calling it with PTHREAD_RWLOCK_INITIALIZER, and > handle the case for Android by itself? You would have a broader coverage > by default and avoid having to add lots of individual cases as you hit them.
That's a good question. Yes, sometimes configure tests can be formulated in a generic way (i.e. "on all platforms where PTHREAD_RWLOCK_INITIALIZER is not defined") or in a specific way (i.e. "on Mac OS X < 10.5") or in an intermediate way (i.e. "on all macOS version which lack PTHREAD_RWLOCK_INITIALIZER"). When autoconf was created, in the 1990ies, new OS versions were frequently forked off from existing OS versions. So, if a bug was detected, say, in Solaris, there were good chances that the same bug also existed in SINIX or perhaps IRIX. And if a bug existed in SunOS 4, there were chances that it existed also in Ultrix. In these times, configure tests should better be generic. Nowadays, the set of OSes has stabilized. Let's look, for example, at the bugs in the <fenv.h> functions that I discovered in the last three weeks: - 22 bugs are specific to a single platform. - 11 bugs exist on two or more platforms. Also, remember that a generic test - takes longer to write than a specific test, - may fail on other platforms for unrelated reasons. Therefore, when 2/3 of all bugs are specific to a single platform, it often is overkill to use a generic test. It just depends on the nature of the bug. Here, in this case, I chose to put in a workaround only for macOS, because I hope that if the problem (PTHREAD_RWLOCK_INITIALIZER being undefined) occurs on other platforms, it has better workarounds: defining some platform-specific macro, using PTHREAD_RWLOCK_INITIALIZER_NP, or some other obvious initializer). Bruno
