gmail really needs to stop mark cboard mail as spam, anyways I ultimately found semget & co and now default to those instead since I can forcefully invalidate the semaphore at compile time by defining INVALID_NPAWSEM as -1. As far as "randomly become invalid" I meant that a pointer used as though it were valid can cause the app to crash. Worse still if the same expectations were applied in the kernel it could crash the entire kernel. If on the other hand I use something only the kernel can control the validity and type of then when a thread attempts to use a just invalidated semaphore the kernel will see the descriptor/handle (in the case of windows) as either not pointing to any object in the list of objects it has and thus flag as invalid or see it's pointing to something not a semaphore which will also cause it to flag as invalid. There's still an edge case of the hook being given to a new semaphore at which point the kernel can't detect the error but that's possibly catch-able with multiple copies of the hook.
As far as posix not defining how sem_t is defined, that's fine as the header is always native. However because the header is always native posix should define a define for implementations to define for compile time invalidation. Something as simple as #define COMPILE_TIME_INVALID_SEM_T ... would've been fine. No need for code to look into the details of the semaphore. They just need to set their semaphore like this then:
Code:
sem_t s = COMPILE_TIME_INVALID_SEM_T;
void *thread_foo(void*) { if ( sem_wait(s) != 0 && errno == EINVALID ) return NULL; ... }
int main(...) { ... pthread_create(thread_foo,...); ... }
Without the define it's ambiguous if main managed to somehow skip initialising s with sem_init(), it's entirely possible that during intial load of the executable the memory space s sits in just so happens to look like a valid semaphore which is definitely not thread safe and thus not the intent of sem_t.