Re: [PATCH] Don't divide by zero when trying to destroy an uninitialised barrier.

[Szabolcs Nagy <szabolcs dot nagy at arm dot com>]

On 20/04/16 17:48, Mark Thompson wrote:
> ---
>  nptl/pthread_barrier_destroy.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/nptl/pthread_barrier_destroy.c b/nptl/pthread_barrier_destroy.c
> index 92d2027..d114084 100644
> --- a/nptl/pthread_barrier_destroy.c
> +++ b/nptl/pthread_barrier_destroy.c
> @@ -36,6 +36,15 @@ pthread_barrier_destroy (pthread_barrier_t *barrier)
>       they have exited as well.  To get the notification, pretend that we have
>       reached the reset threshold.  */
>    unsigned int count = bar->count;
> +
> +  /* For an initialised barrier, count must be greater than zero here.  An
> +     uninitialised barrier may still have zero, however, and in this case it is
> +     preferable to fail immediately rather than to invoke undefined behaviour
> +     by dividing by zero on the next line.  (POSIX allows the implementation to
> +     diagnose invalid state and return EINVAL in this case.)  */
> +  if (__glibc_unlikely (count == 0))
> +    return EINVAL;
> +

this case is undefined behaviour in posix, and
i think the best way to handle that is crashing.
(because no behaviour can be portably relied upon)

nowadays posix says
"The [EINVAL] error for an uninitialized barrier
attributes object is removed; this condition
results in undefined behavior."

>    unsigned int max_in_before_reset = BARRIER_IN_THRESHOLD
>                                    - BARRIER_IN_THRESHOLD % count;
>    /* Relaxed MO sufficient because the program must have ensured that all
>