We have a relatively new struct in perl.h that looks like this: typedef struct { perl_mutex lock; perl_cond wakeup; Size_t readers_count; } perl_RnW1_mutex_t; Meanwhile, over in thread.h, we have a number of macros that do things like the following to make sure the unsigned readers_count does not go negative: if ((mutex)->readers_count <= 0) { \ assert((mutex)->readers_count == 0); \ (mutex)->readers_count = 0; \ break; \ } \ That seems pretty pointless to me since an unsigned value can't go negative. Should we make readers_count SSize_t rather than Size_t, or should we get rid of the check for negative values? I ask because the compiler I'm using complains as follows in a couple dozen places. GETENV_UNLOCK; ...^ %CC-I-QUESTCOMPARE, In this statement, the unsigned expression "(&PL_env_mutex)->readers_count" is being compared with a relational operator to a constant whose value is not greater than zero. This might not be what you intended. at line number 2802 in file SMOKE_BUILD_ROOT:[blead]inline.h;1 This recently broke the build until I relaxed Time::HiRes's configuration code and still causes at least one test failure (porting/extrefs.t). If the intent was to limit the number of readers on a mutex, there must be some more reasonable way to specify the range than depending on integer wraparound to let us know there are too many. I think we would run into resource exhaustion long before getting anywhere near INT_MAX readers.Thread Next