From owner-freebsd-standards@freebsd.org Thu Feb 22 10:56:00 2018 Return-Path: Delivered-To: freebsd-standards@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BB687F2173F for ; Thu, 22 Feb 2018 10:56:00 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5C3767AF84 for ; Thu, 22 Feb 2018 10:56:00 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-yw0-x234.google.com with SMTP id b70so1531852ywh.5 for ; Thu, 22 Feb 2018 02:56:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=n+FXbM8/QtXGjMqYWSAjFWJF0vtAshXwZkri3i6Rbcc=; b=eGxy+L3IhEwPfYI04JLDuaHrlKS7UENxUgbfnmbLr87XFu+qYKV2MKLPWvlmOywXZg ty+dL04oOvZN/pe/l20GxvMISGPj5lCdpjGIUScXaBE/x0sxp872tVcTTWoIB0pwpumB pG5dY+Qmiaa1N7LbtF6Twu2PZR89+nRRGiOg0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=n+FXbM8/QtXGjMqYWSAjFWJF0vtAshXwZkri3i6Rbcc=; b=MB577FzKffHFK5v3+5FVaU0y55PnVReV9Fy2t3E75zBs/15IYTJb2nRr2se8dTjzm/ yHa3iUIKYm7SaUapblQRFMUhgtGmzoE67cUJzkvB8SzU7LScYbMTTo0DLxr3Adq4xFfo +T9cOmzPx3Ac1BQ5/6PIPUNZgQZ9PTO3WUyz6p3BXX+/R9GzWAr9ivuXN2SK3oUaFfH6 iVONYWWBqELuTgGlJlzeLNR5e7h7sLuJBSZsNRO0slqXBKpUt7KiL0lxL6h/WN25yf2S uK5GkWSjrst9TfuEBX5/D8420g1kaOejgQNr1XSIAefbTroGVDsyZ+DrIBUsjo8QDnIf 8WfQ== X-Gm-Message-State: APf1xPCSUqCC1HoDZFhaf53i1ewkemJA3LwTwJwhHoem2Fgj6wdbb+rj w5uUT6uC1E4RYZhcjhmBcP3PFe3zvXgvMdsKLEmVk/4H X-Google-Smtp-Source: AH8x225azh6GAFqWcYX2+vNixYx3v7F0YlcrwUheSjQVm43YP6CNYLmvB7f4rOLrOfOhOey08wjTvhFzsW9mwv+Aeno= X-Received: by 10.13.195.131 with SMTP id f125mr4299920ywd.387.1519296959611; Thu, 22 Feb 2018 02:55:59 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a25:dfcb:0:0:0:0:0 with HTTP; Thu, 22 Feb 2018 02:55:29 -0800 (PST) In-Reply-To: <23181.50488.186767.579361@khavrinen.csail.mit.edu> References: <20180221032247.GA81670@ns.kevlo.org> <20180221104400.GU94212@kib.kiev.ua> <23181.46427.671514.319710@khavrinen.csail.mit.edu> <20180221185920.GA94212@kib.kiev.ua> <23181.50488.186767.579361@khavrinen.csail.mit.edu> From: Eitan Adler Date: Thu, 22 Feb 2018 02:55:29 -0800 Message-ID: Subject: Re: Marking select(2) as restrict To: Garrett Wollman Cc: Konstantin Belousov , FreeBSD Standards Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 10:56:01 -0000 On 21 February 2018 at 11:15, Garrett Wollman wrote: > < said: > >>> [I wrote:] >>> Compliance with the 2001 POSIX standard (and subsequent versions). >>> >>> After C99, all POSIX interfaces that use pointers were updated to >>> include the restrict qualifier where applicable. > >> Restrict barely puts any requirements on the implementation, but does on >> the consumers. Which is the cause of this discussion. > > I can't speak to this particular case, but my understanding is that > "restrict" qualifier was only added to arguments if the behavior was > already unspecified or undefined when the pointers in question were > aliases (so the consumer was already broken if it did so). Certainly > such code has been broken for the better part of two decades. > >> Also, what incompliance consequences are ? I am not even sure that the >> prototype mismatch can be detected by means other than parsing the headers. > > It is permissible for an application to explicitly declare any > function defined in the standard, so long as it uses the prototype set > out in the standard. Also, any vendor wanting POSIX or UNIX > certification for a derivative system would have to fix it anyway. Basically this: it is required by the standard. In addition glibc uses this so its seems unlikely that any modern software will rely on not-restrict. https://github.com/bminor/glibc/blob/master/misc/sys/select.h#L101 -- Eitan Adler