On 2025-07-06, Ingo Schwarze wrote:
> Hello Ted,
> 
> Ted Unangst wrote on Sat, Jul 05, 2025 at 12:31:52PM -0400:
> 
> > And now the same for mutex. Pretty much same as before.
> > 
> > I removed some description text about errors that duplicates the errors
> > section. I preserved the partial lie about unlock returning an error.
> 
> OK schwarze@ except that you need to sort ERRORS and that you broke
> STANDARDS.

Sort by error number? It is currently sorted by the function. I think that
is more useful. I would not typically look for an error, and then see if it
applies to my function.

> The simplest way to fix this is to just keep the text as it is, i.e.
> 
> The functions
> .Fn pthread_mutex_init ,
> .Fn pthread_mutex_destroy ,
> and
> .Fn pthread_mutex_unlock
> conform to
> .St -p1003.1-96 .
> The functions
> .Fn pthread_mutex_lock ,
> .Fn pthread_mutex_timedlock ,
> and
> .Fn pthread_mutex_trylock
> conform to
> .St -p1003.1-2008 .
> 
> That lazy copout seems acceptable for now, but not very good in the
> long run.  It is likely to make readers wonder why we conform to
> inconsistent standards.  It would seem desirable to check whether we
> conform to -p1003.1-2024 and update to that if we do.

Heh, well, I don't think I would have suggested that, but if you're okay 
with it, then I guess. But...

> It appears that guenther@ checked on 2012/02/24 that the three *lock*
> functions conform to -p1003.1-2008 but didn't go any further than that.

Checking, there are some discrepancies. Most or all of the EINVAL 
checks have been removed, in favor of undefined behavior. Our implementation
is compliant, but we don't distinguish between standard required and standard
permitted behavior. A conformant application cannot rely on these checks.

Also, our prototypes are missing the restrict keyword.