gustavonihei commented on pull request #4246: URL: https://github.com/apache/incubator-nuttx/pull/4246#issuecomment-888497055
> > Quoting from the Description section of standard latest version: > > > The behavior is undefined if the value specified by the attr argument to pthread_barrierattr_destroy() does not refer to an initialized barrier attributes object. > > > > > > And the update on Issue 7: > > > The [EINVAL] error for an uninitialized barrier attributes object is removed; this condition results in undefined behavior. > > I think that "an uninitialized barrier attributes" mean the content of pointer(*attr), not pointer self(attr). The NULL pointer is always invalid. > Does the `-EINVAL` return code really matters for the callers of `pthread_barrierattr_destroy`? Probably no one will explicitly check for `-EINVAL`. If the idea for returning the error code is just for it to not go unnoticed, a `DEBUGASSERT(attr != NULL)` does a better job. And still the implementation remains compliant to the standard. > > https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_barrierattr_destroy.html > > So `pthread_barrierattr_destroy` should simply return 0, which is the same behavior from other implementations: > > > > * glibc: https://chromium.googlesource.com/chromiumos/third_party/glibc/+/refs/heads/master/nptl/pthread_barrierattr_destroy.c > > * musl: http://git.musl-libc.org/cgit/musl/tree/src/thread/pthread_barrierattr_destroy.c > > But openbsd check it: > https://github.com/openbsd/src/blob/master/lib/librthread/rthread_barrier_attr.c -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
