From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 63533 invoked by alias); 20 Apr 2016 19:16:23 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 63514 invoked by uid 89); 20 Apr 2016 19:16:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=pubsopengrouporg, sk:pubsop, onlinepubs, UD:opengroup.org X-HELO: mail-wm0-f44.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=0FQTMfOOAopTD1OqnRK9GdlQkCzvwFDH72rWyHMVai8=; b=lbmkEvztTZ4om/mZ5jPl1vZfrNLuxkd4oAp6r1XYUxQZ571gQ6HHTqRvWUXH0E9A+p Mh6SUJureXwH+tGBAiN4oVjfTVMU7IjZyG89zV0ZmWGxhLcGi7PFqQ5NS6/WFal9bF+z d1VFTo1BV8OQxeRJhgRvqi09FM8pTNCOno6PqlfeQmO0ufZcTxduRT3QSq9U2sbD+5Bo 0Lq34UVbQt7s2O8ueaXaDcTx8Lse4VfP9fwmb306oBRknpdINcF54ucV3kNagN6FyND4 AND4Ikk/99LedcsDAttqMFLBkUXHQlrSIHr8wvFH1G4WgUWYGmH0/7Yjk5X190tGJlKU dTYg== X-Gm-Message-State: AOPr4FWc0zaApiv3BxzKvX6iuX5QQXsuRlf0yvyLNjn4bshf1HZL1JfZ02NHSgtEGyR4maLg X-Received: by 10.28.141.141 with SMTP id p135mr30362836wmd.8.1461179769874; Wed, 20 Apr 2016 12:16:09 -0700 (PDT) Subject: Re: [PATCH] Don't divide by zero when trying to destroy an uninitialised barrier. To: Szabolcs Nagy , GNU C Library References: <5717B2F4.9050105@starleaf.com> <5717B657.6040007@arm.com> Cc: nd From: Mark Thompson Message-ID: <5717D575.40806@starleaf.com> Date: Wed, 20 Apr 2016 19:16:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.6.0 MIME-Version: 1.0 In-Reply-To: <5717B657.6040007@arm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-04/txt/msg00502.txt.bz2 On 20/04/16 18:03, Szabolcs Nagy wrote: > 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) The undefined behaviour is not necessarily crashing - systems which do not trap on divide by zero (such as aarch64) will do something else, such as returning success or hanging forever. Would you prefer an abort() be added to make the behavior consistent? > nowadays posix says > "The [EINVAL] error for an uninitialized barrier > attributes object is removed; this condition > results in undefined behavior." It also says: "If an implementation detects that the value specified by the barrier argument to pthread_barrier_destroy() does not refer to an initialized barrier object, it is recommended that the function should fail and report an [EINVAL] error." ()