From owner-freebsd-standards@freebsd.org Sun Feb 18 05:37:27 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 AFD8CF13B22 for ; Sun, 18 Feb 2018 05:37:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4885483C8B for ; Sun, 18 Feb 2018 05:37:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 6C933223A7 for ; Sun, 18 Feb 2018 05:37:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w1I5bQl4034721 for ; Sun, 18 Feb 2018 05:37:26 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w1I5bQsM034720 for freebsd-standards@FreeBSD.org; Sun, 18 Feb 2018 05:37:26 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-standards@FreeBSD.org Subject: [Bug 225864] malformed dates with current Catalan timedef files Date: Sun, 18 Feb 2018 05:37:25 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: standards X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: rbuj@fedoraproject.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-standards@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Sun, 18 Feb 2018 05:37:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D225864 --- Comment #1 from Robert Buj Gelonch --- Created attachment 190742 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D190742&action= =3Dedit Timedef settings for Catalan --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-standards@freebsd.org Wed Feb 21 04:52:05 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 8DB92F031F1 for ; Wed, 21 Feb 2018 04:52:05 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (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 310D985838 for ; Wed, 21 Feb 2018 04:52:02 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-yw0-x233.google.com with SMTP id y186so132189ywf.7 for ; Tue, 20 Feb 2018 20:52:02 -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=87+jY1Jz7UxZaZvpNHNkdVrbgGotLdqJrBJ6d1BgE50=; b=glEIgpkll3IqLn8kj7gfIgyizcHGLyf+n8QumDjU2OJKDNNDCXCAA9juJMjq679L61 mc93RCjCXU1OJPNMVAgE8Q4ATopXBOFSai99cMj1j2HmA3zrDRwmbMXQTH7we1dL6W9n udb7h5FdUM7H3TslJhPY8qzYaYshBnybWGwo8= 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=87+jY1Jz7UxZaZvpNHNkdVrbgGotLdqJrBJ6d1BgE50=; b=NS4TAuXDbeZUDGLH9jl1T2sLzAUVhegJ9h4FSZCezI2ebin/NPduGfKlLicQAWZ8ea CgxmMqCBlroo83qByRJ/2TlP/XZXSBf7KfYhr57ac7mrcxsTnrAdrSz0UIaq0V+nP8pB PunLjCZrNisYt/13NK975jfcMZymnekKHMaVlkprJu9tTswOqCaMcdahItH5liJnVlZD wRbjT8FP0DZOYyXLhfpUAyiY3gFKj5Vc6daf1pzX5JsVDpvWVomWk/F/DMKu7IN2/v3V YHXVMSrPZs+XExCvAjW+PbM1YHIPSDIW2T19+twfHLeid0CT85J/MeFRrmjfibJO2nlB HGVw== X-Gm-Message-State: APf1xPA9BI0cveLTybD4uz4SbJKuUy9kB9BYqmEIwzjKPN+V/vjvw0AE AeFsanlbzLxl5e1cP2O9QYGWgZdBr+2IrWIJWbIe7Q== X-Google-Smtp-Source: AH8x226+5NxN/OfgBLzVW91wh20LM03CDGT1yvkMZ+5nMz0wKtG0kFt6nWhHy6C9Igr5NKKH7pNBGS9Kc3ZoKkPBFdM= X-Received: by 10.13.214.214 with SMTP id y205mr1416048ywd.37.1519188721582; Tue, 20 Feb 2018 20:52:01 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a25:dfcb:0:0:0:0:0 with HTTP; Tue, 20 Feb 2018 20:52:00 -0800 (PST) In-Reply-To: <20180221032247.GA81670@ns.kevlo.org> References: <20180221032247.GA81670@ns.kevlo.org> From: Eitan Adler Date: Tue, 20 Feb 2018 20:52:00 -0800 Message-ID: Subject: Re: Marking select(2) as restrict To: Kevin Lo , FreeBSD Standards Cc: FreeBSD Hackers , Warner Losh Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 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: Wed, 21 Feb 2018 04:52:05 -0000 Adding standards mailing list On Tuesday, 20 February 2018, Kevin Lo wrote: > On Tue, Feb 20, 2018 at 04:29:59PM -0800, Eitan Adler wrote: > > > > I filed a request for a slightly modified version of this patch to be > > exp-run. I'm planning on committing unless there is significant > > fallout or objections on this list. > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225981 > > Please send your patch to standards@. The freebsd-standards mailing list > was created for precisely this purpose, thanks. > > > On 15 February 2018 at 00:10, Eitan Adler wrote: > > > Hi all, > > > > > > POSIX requires that the fd_set arguments in select(2) be marked as > > > restrict. This patch attempts to implement that. > > > > > > (a) Am I missing anything? > > > (b) Anything in particular to watch out for? > > > (c) Assuming an exp-run passes any reason not to commit? > > > > > > > > > Index: lib/libc/sys/select.2 > > > =================================================================== > > > --- lib/libc/sys/select.2 (revision 329296) > > > +++ lib/libc/sys/select.2 (working copy) > > > @@ -39,7 +39,7 @@ > > > .Sh SYNOPSIS > > > .In sys/select.h > > > .Ft int > > > -.Fn select "int nfds" "fd_set *readfds" "fd_set *writefds" "fd_set > > > *exceptfds" "struct timeval *timeout" > > > +.Fn select "int nfds" "fd_set * restrict readfds" "fd_set * restrict > > > writefds" "fd_set * restrict exceptfds" "struct timeval *timeout" > > > .Fn FD_SET fd &fdset > > > .Fn FD_CLR fd &fdset > > > .Fn FD_ISSET fd &fdset > > > Index: lib/libc/sys/select.c > > > =================================================================== > > > --- lib/libc/sys/select.c (revision 329296) > > > +++ lib/libc/sys/select.c (working copy) > > > @@ -41,7 +41,7 @@ __weak_reference(__sys_select, __select); > > > > > > #pragma weak select > > > int > > > -select(int n, fd_set *rs, fd_set *ws, fd_set *es, struct timeval *t) > > > +select(int n, fd_set * restrict rs, fd_set * restrict ws, fd_set * > > > restrict es, struct timeval *t) > > > { > > > > > > return (((int (*)(int, fd_set *, fd_set *, fd_set *, struct timeval > *)) > > > Index: sys/sys/select.h > > > =================================================================== > > > --- sys/sys/select.h (revision 329296) > > > +++ sys/sys/select.h (working copy) > > > @@ -101,8 +101,7 @@ int pselect(int, fd_set *__restrict, fd_set *__res > > > const struct timespec *__restrict, const sigset_t *__restrict); > > > #ifndef _SELECT_DECLARED > > > #define _SELECT_DECLARED > > > -/* XXX missing restrict type-qualifier */ > > > -int select(int, fd_set *, fd_set *, fd_set *, struct timeval *); > > > +int select(int, fd_set *__restrict, fd_set *__restrict, fd_set > > > *__restrict, struct timeval *); > > > #endif > > > __END_DECLS > > > #endif /* !_KERNEL */ > > > > > > > > > -- > > > Eitan Adler > > > > > > > > -- > > Eitan Adler > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to " > freebsd-hackers-unsubscribe@freebsd.org" > > > -- Sent from my Turing Machine From owner-freebsd-standards@freebsd.org Wed Feb 21 05:19:02 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 756E7F0519D for ; Wed, 21 Feb 2018 05:19:02 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 03FC586664 for ; Wed, 21 Feb 2018 05:19:02 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x232.google.com with SMTP id 30so825187iog.2 for ; Tue, 20 Feb 2018 21:19:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=m4sPwmQigNOQQJi/tKhRkjiKy4ZYnCrWG7adkLIiYJg=; b=bcXZWlxud9dOu3tE1g/KBx25GL+E3qLYsebAE5R9BcxHGnCT5+QMlznu5wzNBIHUFq bOBqpNQyIr9y3Om0oWC+1sCMuv6EvDLgGALFh34vNac8H4FnThM4XKRABfrrsIlGmJd6 2hn+melm1Ug2Q4pOKSHJ2zhIWfhfb7FbOcGoSu7YfKbQffuFLi46CKJxYseP/Mxc0de/ n8Pg8vm14tGiNts6Rozd3iRf7flLILggvz0fyLLKGKGy9YpZeyzvABhbXe5hoYoGbREE iZO/3cuJOIDK6NnK++Qq+9inn7OOLp0sPTQQ6IBUNTDAdEFcFEc2j5G/QKGrIN4u90+T OWeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=m4sPwmQigNOQQJi/tKhRkjiKy4ZYnCrWG7adkLIiYJg=; b=aYsatcYps3wI2Ek4NjT62bNO7nvHdHjZnn7s9DKyxLhSTWpVaBkTl07oVXQiqOWqvf 6YVRKGwEkp1anKB/0cDFPh61SGe+bkPPidaY9biZFcwpk3AlGfuu9hz7NNBvl6MCLP2/ O/XIEvwjD/9Wpq/zR0mO9EKsPxhVwXyO79yWOhhXZz8Z3vYHw9wPBI/X4GmAwCiFU5rm NwQpfW21IrTfDeYovlz7Fynoknv9/ZmpninisyQ24KRR/GHIy1A4YExtorHXJxm/BWkG zpz6h+DXgOJbsya1rUgm7bkpSjRt8H021qIcU610G7Copn8UQp8+7fXu6LdIE8YMYZ/R FfxA== X-Gm-Message-State: APf1xPAkEpLZZJ6Ji54v35lQOY86sfxwb6K6GwWDbxusF8P1RB9ryzfy o7v3Bc8vnK/6LphhAdiDN0EQN+OnnT67EpCdLyOjxw== X-Google-Smtp-Source: AG47ELvp+6Rpq1CKNipFUtqxiGkg0Wmp5pfqysSY8m52ACok3fgVkhrh7JsAU6A0Jr2ks1JdzIE5kJWdjkgveXv/KAg= X-Received: by 10.107.175.77 with SMTP id y74mr2724896ioe.37.1519190341199; Tue, 20 Feb 2018 21:19:01 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.201.67 with HTTP; Tue, 20 Feb 2018 21:19:00 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:9198:c568:89aa:9c67] Received: by 10.79.201.67 with HTTP; Tue, 20 Feb 2018 21:19:00 -0800 (PST) In-Reply-To: References: <20180221032247.GA81670@ns.kevlo.org> From: Warner Losh Date: Tue, 20 Feb 2018 22:19:00 -0700 X-Google-Sender-Auth: 2aoxrDjCPShCvlqRVEjvQVupYYw Message-ID: Subject: Re: Marking select(2) as restrict To: Eitan Adler Cc: Kevin Lo , freebsd-standards@freebsd.org, FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 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: Wed, 21 Feb 2018 05:19:02 -0000 On Feb 20, 2018 9:52 PM, "Eitan Adler" wrote: Adding standards mailing list On Tuesday, 20 February 2018, Kevin Lo wrote: > On Tue, Feb 20, 2018 at 04:29:59PM -0800, Eitan Adler wrote: > > > > I filed a request for a slightly modified version of this patch to be > > exp-run. I'm planning on committing unless there is significant > > fallout or objections on this list. > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225981 > > Please send your patch to standards@. The freebsd-standards mailing list > was created for precisely this purpose, thanks. > > > On 15 February 2018 at 00:10, Eitan Adler wrote: > > > Hi all, > > > > > > POSIX requires that the fd_set arguments in select(2) be marked as > > > restrict. This patch attempts to implement that. > > > > > > (a) Am I missing anything? > > > (b) Anything in particular to watch out for? > > > (c) Assuming an exp-run passes any reason not to commit? > > > > > > > > > Index: lib/libc/sys/select.2 > > > =================================================================== > > > --- lib/libc/sys/select.2 (revision 329296) > > > +++ lib/libc/sys/select.2 (working copy) > > > @@ -39,7 +39,7 @@ > > > .Sh SYNOPSIS > > > .In sys/select.h > > > .Ft int > > > -.Fn select "int nfds" "fd_set *readfds" "fd_set *writefds" "fd_set > > > *exceptfds" "struct timeval *timeout" > > > +.Fn select "int nfds" "fd_set * restrict readfds" "fd_set * restrict > > > writefds" "fd_set * restrict exceptfds" "struct timeval *timeout" > > > .Fn FD_SET fd &fdset > > > .Fn FD_CLR fd &fdset > > > .Fn FD_ISSET fd &fdset > > > Index: lib/libc/sys/select.c > > > =================================================================== > > > --- lib/libc/sys/select.c (revision 329296) > > > +++ lib/libc/sys/select.c (working copy) > > > @@ -41,7 +41,7 @@ __weak_reference(__sys_select, __select); > > > > > > #pragma weak select > > > int > > > -select(int n, fd_set *rs, fd_set *ws, fd_set *es, struct timeval *t) > > > +select(int n, fd_set * restrict rs, fd_set * restrict ws, fd_set * > > > restrict es, struct timeval *t) > > > { > > > > > > return (((int (*)(int, fd_set *, fd_set *, fd_set *, struct timeval > *)) > > > Index: sys/sys/select.h > > > =================================================================== > > > --- sys/sys/select.h (revision 329296) > > > +++ sys/sys/select.h (working copy) > > > @@ -101,8 +101,7 @@ int pselect(int, fd_set *__restrict, fd_set *__res > > > const struct timespec *__restrict, const sigset_t *__restrict); > > > #ifndef _SELECT_DECLARED > > > #define _SELECT_DECLARED > > > -/* XXX missing restrict type-qualifier */ > > > -int select(int, fd_set *, fd_set *, fd_set *, struct timeval *); > > > +int select(int, fd_set *__restrict, fd_set *__restrict, fd_set > > > *__restrict, struct timeval *); > > > #endif > > > __END_DECLS > > > #endif /* !_KERNEL */ > Once upon a time, this would break a lot of code. Perhaps times have changed. Does the state of the art give warnings,when restrict is violated? If not, how do you propose the ports broken subtlely be detected? Warner From owner-freebsd-standards@freebsd.org Wed Feb 21 06:14:37 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 16124F08649 for ; Wed, 21 Feb 2018 06:14:37 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002:c09::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 A3FB468663 for ; Wed, 21 Feb 2018 06:14:36 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-yb0-x234.google.com with SMTP id p77-v6so183761yba.5 for ; Tue, 20 Feb 2018 22:14:36 -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=46bdcs421TJ4f9uLhJEPcomtuF0utsyTayp8Bvgr6SQ=; b=W3QbIjzSQ77F2havxZPHL71NI2y1AwG/WAxNhY8CGGP/m/94ImPLKG18/kocm6D6CL OTCYLHca8o6MvI9xP6ayDrHN46DUZR7Pqm9nSb9FdDj5IKb5no9hbSQRP+m30yERlI7B Mh2/Nxq66FRIQ1PBYOU9VTYvqNn+e1z5pgUg8= 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=46bdcs421TJ4f9uLhJEPcomtuF0utsyTayp8Bvgr6SQ=; b=O6uY1JS5eulnebvUSi/7YN1sM8aTTOokBIQjAwAEHYnfKWg7DukzvDG6mcjlRdHJLZ sda00mA9YA3PkYzFRSfX/4WURgUe6GbkT3xn8mnhs+mTcacXdgMaNdMM6vEDMFVHXaze YrUP1OgI/XnlxTplnWtaeAkKW41ltJBOmV3Dp60jxxm/zUYqLho2j9BJIdinNctWinys 1ZRyNvQXzQIxsYwqSrxv5fJR9cwWz2tEPpaAsoxg53IJnAMiXf8nOCUb0NiySAxp6Fs4 33xZxdADDxnB3bIIFlIpnUs3drWmF/PAWvdc1sBHBeYLunMyIu+OVE/Mmm5N/BzJzc5x v8rA== X-Gm-Message-State: APf1xPDaLFL9qTw9oNrxAceOFRaSsk9y/buLbUtQ56+B8VITJwLTweVG Q+AdP+hiGAjqcYTH1kw9z54dctIp5h70DcKcr2V1OsBn X-Google-Smtp-Source: AH8x224NxJfskrNMCjN20+XUIMvbwLp1KfOEQUfEyD13dxoMxmWYhu3Z7L9avA1NvKJyKQEKJUkiO99ptT+tG2jjMfc= X-Received: by 2002:a25:86c5:: with SMTP id y5-v6mr1562437ybm.194.1519193676084; Tue, 20 Feb 2018 22:14:36 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a25:dfcb:0:0:0:0:0 with HTTP; Tue, 20 Feb 2018 22:14:05 -0800 (PST) In-Reply-To: References: <20180221032247.GA81670@ns.kevlo.org> From: Eitan Adler Date: Tue, 20 Feb 2018 22:14:05 -0800 Message-ID: Subject: Re: Marking select(2) as restrict To: Warner Losh Cc: Kevin Lo , FreeBSD Standards , FreeBSD Hackers 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: Wed, 21 Feb 2018 06:14:37 -0000 On 20 February 2018 at 21:19, Warner Losh wrote: > Once upon a time, this would break a lot of code. Perhaps times have > changed. I've seen very little code that this would break though some of it certainly exists. > Does the state of the art give warnings,when restrict is violated? In the general case it can not since aliasing may occur through run-time warnings. Modern compilers can warn in specific sub-cases though: restrict.c:10:6: warning: passing argument 1 to restrict-qualified parameter aliases with argument 2 [-Wrestrict] meh(&a, &a); > If not, > how do you propose the ports broken subtlely be detected? My plan was to commit to current but not MFC. This would allow users to detect issues and report them. Another option is to request that POSIX change the definition of select to not require restrict though I am doubtful this will happen. -- Eitan Adler From owner-freebsd-standards@freebsd.org Wed Feb 21 10:44:18 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 8171DF1C787; Wed, 21 Feb 2018 10:44:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EF83672198; Wed, 21 Feb 2018 10:44:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w1LAi1SB084085 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 21 Feb 2018 12:44:04 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w1LAi1SB084085 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w1LAi0xC084083; Wed, 21 Feb 2018 12:44:00 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 21 Feb 2018 12:44:00 +0200 From: Konstantin Belousov To: Eitan Adler Cc: Warner Losh , Kevin Lo , FreeBSD Standards , FreeBSD Hackers Subject: Re: Marking select(2) as restrict Message-ID: <20180221104400.GU94212@kib.kiev.ua> References: <20180221032247.GA81670@ns.kevlo.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.3 (2018-01-21) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home 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: Wed, 21 Feb 2018 10:44:18 -0000 On Tue, Feb 20, 2018 at 10:14:05PM -0800, Eitan Adler wrote: > On 20 February 2018 at 21:19, Warner Losh wrote: > > Once upon a time, this would break a lot of code. Perhaps times have > > changed. > > I've seen very little code that this would break though some of it > certainly exists. You certainly seen very little code, but the question was about the existed code. > > > Does the state of the art give warnings,when restrict is violated? > > In the general case it can not since aliasing may occur through > run-time warnings. Modern compilers can warn in specific sub-cases > though: What run-time warnings ? Point out the code that issues them in the case of restrict (or generic aliasing) violation. In libc ? In kernel ? Did you even tried to estimate how many code around still requires disabling alias analysis to run ? How does restrict mix with no-aliasing option ? Above question contains a hint how it is possible to detect existing calls which violate the restrict specifier for select(2), but this requires running of all select(2) consumers, on patched kernel or libc/libthr. > > restrict.c:10:6: warning: passing argument 1 to restrict-qualified > parameter aliases with argument 2 [-Wrestrict] > meh(&a, &a); > > > If not, > > how do you propose the ports broken subtlely be detected? > > My plan was to commit to current but not MFC. This would allow users > to detect issues and report them. And, how to do plan to classify the bugs appeared due the change ? What specific indicators would allow you to find them out in the stream of the bug reports ? > > Another option is to request that POSIX change the definition of > select to not require restrict though I am doubtful this will happen. I fail to find an explanation of the supposed benefit of the change you proposing. Please point it out. From owner-freebsd-standards@freebsd.org Wed Feb 21 18:07:25 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 20F33F1A852 for ; Wed, 21 Feb 2018 18:07:25 +0000 (UTC) (envelope-from wollman@khavrinen.csail.mit.edu) Received: from khavrinen.csail.mit.edu (khavrinen.csail.mit.edu [IPv6:2603:400a:0:7ec::801e:1c14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "khavrinen.csail.mit.edu", Issuer "Client CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C2AC16927A for ; Wed, 21 Feb 2018 18:07:24 +0000 (UTC) (envelope-from wollman@khavrinen.csail.mit.edu) Received: from khavrinen.csail.mit.edu (localhost [127.0.0.1]) by khavrinen.csail.mit.edu (8.15.2/8.15.2) with ESMTPS id w1LI7N4G000245 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL CN=khavrinen.csail.mit.edu issuer=Client+20CA); Wed, 21 Feb 2018 13:07:24 -0500 (EST) (envelope-from wollman@khavrinen.csail.mit.edu) Received: (from wollman@localhost) by khavrinen.csail.mit.edu (8.15.2/8.15.2/Submit) id w1LI7N0Q000244; Wed, 21 Feb 2018 13:07:23 -0500 (EST) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23181.46427.671514.319710@khavrinen.csail.mit.edu> Date: Wed, 21 Feb 2018 13:07:23 -0500 From: Garrett Wollman To: Konstantin Belousov Cc: freebsd-standards@freebsd.org Subject: Re: Marking select(2) as restrict In-Reply-To: <20180221104400.GU94212@kib.kiev.ua> References: <20180221032247.GA81670@ns.kevlo.org> <20180221104400.GU94212@kib.kiev.ua> X-Mailer: VM 8.2.0b under 25.3.1 (amd64-portbld-freebsd10.3) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (khavrinen.csail.mit.edu [127.0.0.1]); Wed, 21 Feb 2018 13:07:24 -0500 (EST) 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: Wed, 21 Feb 2018 18:07:25 -0000 < said: > I fail to find an explanation of the supposed benefit of the change > you proposing. Please point it out. 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. -GAWollman From owner-freebsd-standards@freebsd.org Wed Feb 21 18:59:43 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 D36AFF203CB for ; Wed, 21 Feb 2018 18:59:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 293826C598 for ; Wed, 21 Feb 2018 18:59:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w1LIxL1c096385 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 21 Feb 2018 20:59:24 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w1LIxL1c096385 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w1LIxLUI096382; Wed, 21 Feb 2018 20:59:21 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 21 Feb 2018 20:59:20 +0200 From: Konstantin Belousov To: Garrett Wollman Cc: freebsd-standards@freebsd.org Subject: Re: Marking select(2) as restrict Message-ID: <20180221185920.GA94212@kib.kiev.ua> References: <20180221032247.GA81670@ns.kevlo.org> <20180221104400.GU94212@kib.kiev.ua> <23181.46427.671514.319710@khavrinen.csail.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23181.46427.671514.319710@khavrinen.csail.mit.edu> User-Agent: Mutt/1.9.3 (2018-01-21) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home 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: Wed, 21 Feb 2018 18:59:44 -0000 On Wed, Feb 21, 2018 at 01:07:23PM -0500, Garrett Wollman wrote: > < said: > > > > I fail to find an explanation of the supposed benefit of the change > > you proposing. Please point it out. > > 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. Also, what incompliance consequences are ? I am not even sure that the prototype mismatch can be detected by means other than parsing the headers. From owner-freebsd-standards@freebsd.org Wed Feb 21 19:15:05 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 08579F21ACA for ; Wed, 21 Feb 2018 19:15:05 +0000 (UTC) (envelope-from wollman@khavrinen.csail.mit.edu) Received: from khavrinen.csail.mit.edu (khavrinen.csail.mit.edu [IPv6:2603:400a:0:7ec::801e:1c14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "khavrinen.csail.mit.edu", Issuer "Client CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A93816D537 for ; Wed, 21 Feb 2018 19:15:04 +0000 (UTC) (envelope-from wollman@khavrinen.csail.mit.edu) Received: from khavrinen.csail.mit.edu (localhost [127.0.0.1]) by khavrinen.csail.mit.edu (8.15.2/8.15.2) with ESMTPS id w1LJF4xD001021 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL CN=khavrinen.csail.mit.edu issuer=Client+20CA); Wed, 21 Feb 2018 14:15:04 -0500 (EST) (envelope-from wollman@khavrinen.csail.mit.edu) Received: (from wollman@localhost) by khavrinen.csail.mit.edu (8.15.2/8.15.2/Submit) id w1LJF4xf001020; Wed, 21 Feb 2018 14:15:04 -0500 (EST) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23181.50488.186767.579361@khavrinen.csail.mit.edu> Date: Wed, 21 Feb 2018 14:15:04 -0500 From: Garrett Wollman To: Konstantin Belousov Cc: freebsd-standards@freebsd.org Subject: Re: Marking select(2) as restrict In-Reply-To: <20180221185920.GA94212@kib.kiev.ua> References: <20180221032247.GA81670@ns.kevlo.org> <20180221104400.GU94212@kib.kiev.ua> <23181.46427.671514.319710@khavrinen.csail.mit.edu> <20180221185920.GA94212@kib.kiev.ua> X-Mailer: VM 8.2.0b under 25.3.1 (amd64-portbld-freebsd10.3) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (khavrinen.csail.mit.edu [127.0.0.1]); Wed, 21 Feb 2018 14:15:04 -0500 (EST) 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: Wed, 21 Feb 2018 19:15:05 -0000 < 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. -GAWollman From owner-freebsd-standards@freebsd.org Wed Feb 21 20:10:18 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 7C69EF261E5 for ; Wed, 21 Feb 2018 20:10:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A5F39701E9 for ; Wed, 21 Feb 2018 20:10:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w1LKA3TF012844 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 21 Feb 2018 22:10:06 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w1LKA3TF012844 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w1LKA2L7012835; Wed, 21 Feb 2018 22:10:02 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 21 Feb 2018 22:10:02 +0200 From: Konstantin Belousov To: Garrett Wollman Cc: freebsd-standards@freebsd.org Subject: Re: Marking select(2) as restrict Message-ID: <20180221201002.GC94212@kib.kiev.ua> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23181.50488.186767.579361@khavrinen.csail.mit.edu> User-Agent: Mutt/1.9.3 (2018-01-21) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home 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: Wed, 21 Feb 2018 20:10:18 -0000 On Wed, Feb 21, 2018 at 02:15:04PM -0500, 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. Undefined != broken, whatever some compiler vendors try to bluff. > > > 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. For such vendors, backward compatibility with existing software should have different priorities than for us. We need a useful software runnable on the system first, and blue sky stuff like POSIX compliance second. From owner-freebsd-standards@freebsd.org Wed Feb 21 20:27:22 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 65B3EF275D5 for ; Wed, 21 Feb 2018 20:27:22 +0000 (UTC) (envelope-from wollman@khavrinen.csail.mit.edu) Received: from khavrinen.csail.mit.edu (khavrinen.csail.mit.edu [IPv6:2603:400a:0:7ec::801e:1c14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "khavrinen.csail.mit.edu", Issuer "Client CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1534E710BF for ; Wed, 21 Feb 2018 20:27:21 +0000 (UTC) (envelope-from wollman@khavrinen.csail.mit.edu) Received: from khavrinen.csail.mit.edu (localhost [127.0.0.1]) by khavrinen.csail.mit.edu (8.15.2/8.15.2) with ESMTPS id w1LKRLvu003572 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL CN=khavrinen.csail.mit.edu issuer=Client+20CA); Wed, 21 Feb 2018 15:27:21 -0500 (EST) (envelope-from wollman@khavrinen.csail.mit.edu) Received: (from wollman@localhost) by khavrinen.csail.mit.edu (8.15.2/8.15.2/Submit) id w1LKRLqE003571; Wed, 21 Feb 2018 15:27:21 -0500 (EST) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23181.54825.511195.393054@khavrinen.csail.mit.edu> Date: Wed, 21 Feb 2018 15:27:21 -0500 From: Garrett Wollman To: Konstantin Belousov Cc: freebsd-standards@freebsd.org Subject: Re: Marking select(2) as restrict In-Reply-To: <20180221201002.GC94212@kib.kiev.ua> 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> <20180221201002.GC94212@kib.kiev.ua> X-Mailer: VM 8.2.0b under 25.3.1 (amd64-portbld-freebsd10.3) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (khavrinen.csail.mit.edu [127.0.0.1]); Wed, 21 Feb 2018 15:27:21 -0500 (EST) 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: Wed, 21 Feb 2018 20:27:22 -0000 < said: > Undefined != broken, whatever some compiler vendors try to bluff. No, undefined behavior means the application is wrong. Literally anything may happen; the compiler does not enter into it. The compiler is not involved when you free() a pointer into the stack, or pass a null pointer into a library routine that unconditionally dereferences it, or update a string literal; nor is it involved when you pass pointers that alias to a library routine that expects them to point to different objects. In the particular case of select(), there are no guarantees as to the order in which the fd_set objects pointed to by readfds, writefds, and exceptfds will be updated, so applications which alias them are clearly wrong and have been since this interface was introduced in 4.2BSD. -GAWollman From owner-freebsd-standards@freebsd.org Wed Feb 21 21:33:06 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 64663F023C4 for ; Wed, 21 Feb 2018 21:33:06 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (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 BEE9E74603 for ; Wed, 21 Feb 2018 21:33:05 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf0-x22b.google.com with SMTP id y19so4453454lfd.4 for ; Wed, 21 Feb 2018 13:33:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=3QaHLIEkD8Sa47vFaG2Tf/3TROBbRTZSarpFjqaqOww=; b=egQ3KLjqQd1HlCx+EgBDt+j0259WNXknNfJY2Xdf65eoPWZ7dRxehzMTu0Wdk50oo8 z9rwGddb/TxqB7/F+g2abTXZsUlkPwlqNJ6c7yL/YpaAcxJv59b8BOBTwQoMEYScH4TW bQYZ6kkVXaHCVM50b6xLw00zrSZKvBAgopQOgg7lldxuixRb9srFA7pkf9Z+BBrhwRgO wsdVuW7zIgljdroCxq3W72K/7/6U6XwWTS/PU3H1qS1Z9Nvp7iOW2WxXIGjECRiYAcgb XqphzaO4ycv9efZIxyOHWKY3cI7x/J+E1q8wNEGgKRUZFEyHi5YT/KHJ16cyoAV/rKX0 K2YQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=3QaHLIEkD8Sa47vFaG2Tf/3TROBbRTZSarpFjqaqOww=; b=WCOyCKlsm4moFIhqGGSkimihXoKrSvyWpA0UKv8RRtOpoGeB7nqlteqRPsFKsuJ6vp yo2qgPJPwtZ+86Hx7U0J2IXIwM2lU3VqnzqFxeQIm97hcv2Naazj+k8wUdjs/BEOFIHW oWzJJmGcXhod4Th9QtyU9GnGs+h5eQZkT7dA2xKBZPyUqoDkDMP4IKhs6KbPeUhTRmhQ 6+A8ZCcNZnipb9h1hz+5lLOR5tF5kFBMTK/ACQY5qUbS4LWoQtWODr3V8eKSVxdMlpD2 xJehY82YtIXRhmVwE7ct0rxIdVdMCsZDFbJHDoetOD5xYWANLEmkqQsi0J7FyY7+HsIY XAJQ== X-Gm-Message-State: APf1xPBggSQwuFfv32U36PYt9ofwvLIwp7U/hnW20Had9dO1StMZ0AUN Q/KL5559HpaXrkhOntrCgH2AYd4cQaXH8KnxJmZBCg== X-Google-Smtp-Source: AH8x226x63yNDyKa0yiOOUaJGtHu2fHzxdti677V6ISPW64BE3G1A1TdcNuMocvDPtvfULIr7u2KTAfsrNQLZU79NEE= X-Received: by 10.25.181.147 with SMTP id g19mr3666596lfk.47.1519248783866; Wed, 21 Feb 2018 13:33:03 -0800 (PST) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.179.30.66 with HTTP; Wed, 21 Feb 2018 13:33:03 -0800 (PST) From: Alan Somers Date: Wed, 21 Feb 2018 14:33:03 -0700 X-Google-Sender-Auth: NU-ArU1WPUn5tflQq07hgIRA_4c Message-ID: Subject: Using the monotonic clock in time(1)? To: freebsd-standards@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 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: Wed, 21 Feb 2018 21:33:06 -0000 time(1) currently uses the realtime clock, which is undesirable for timing short-lived commands while ntpd is active. I opened a review to add an option to use the monotonic clock instead, but jilles suggested that time should use the monotonic clock unconditionally, since that's almost always better for measuring short durations. However, the Open Group's specification seems to require the real time clock. What do the standards folks think? Is the Open Group spec sufficiently ambiguous and/or wrong that we should switch to the monotonic clock instead? https://reviews.freebsd.org/D14032 http://pubs.opengroup.org/onlinepubs/9699919799/utilities/time.html -alan From owner-freebsd-standards@freebsd.org Wed Feb 21 21:54:10 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 35D13F040DF for ; Wed, 21 Feb 2018 21:54:10 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9522F754B7 for ; Wed, 21 Feb 2018 21:54:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w1LLrs85036676 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 21 Feb 2018 23:53:58 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w1LLrs85036676 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w1LLrsEZ036675; Wed, 21 Feb 2018 23:53:54 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 21 Feb 2018 23:53:54 +0200 From: Konstantin Belousov To: Garrett Wollman Cc: freebsd-standards@freebsd.org Subject: Re: Marking select(2) as restrict Message-ID: <20180221215354.GD94212@kib.kiev.ua> 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> <20180221201002.GC94212@kib.kiev.ua> <23181.54825.511195.393054@khavrinen.csail.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23181.54825.511195.393054@khavrinen.csail.mit.edu> User-Agent: Mutt/1.9.3 (2018-01-21) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home 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: Wed, 21 Feb 2018 21:54:10 -0000 On Wed, Feb 21, 2018 at 03:27:21PM -0500, Garrett Wollman wrote: > < said: > > > Undefined != broken, whatever some compiler vendors try to bluff. > > No, undefined behavior means the application is wrong. Literally > anything may happen; the compiler does not enter into it. The > compiler is not involved when you free() a pointer into the stack, or > pass a null pointer into a library routine that unconditionally > dereferences it, or update a string literal; nor is it involved when > you pass pointers that alias to a library routine that expects them to > point to different objects. Undefined behavior only means that the outcome was not specified in some Sacred Text. If your world is limited by that Text, then of course it is quite bad to have undefined behavior. If you look outside the Text bounds, then it often appears that something was left undefined to provide better portability, where different platforms have different but quite reasonable and intuitive specifications. Best example is the signed integer overflow, which was clearly left undefined to allow other than two-complement representations, and not to allow the parodoxical code transformations. For each integer representation allowed in the C standard, signed overflow, if taken naturally, is very much defined. Or the stuff is undefined due to the omission, etc. It is attempts to provide a retionale explanation to decisions of the compiler writers which clearly contradict to the goals of most programmers to write reliable software based on the expected behavior that makes the situation so confusing. In fact, compiler authors do have their own goals of winning the 0.1% in corner cases of speed tests, and do not care about usability. Sorry for the long rant. > > In the particular case of select(), there are no guarantees as to the > order in which the fd_set objects pointed to by readfds, writefds, and > exceptfds will be updated, so applications which alias them are > clearly wrong and have been since this interface was introduced in > 4.2BSD. No, the worry about restrict in the select(2) declaration should be not about the copyout order. It is more the compiler brokeness which makes things crazy, see above. Compiler would note that some pointers cannot be equal or even point to the overlapping memory regions because they are supplied as restricted arguments to select(2), and this allows it to make conclusions which break the program logic. From owner-freebsd-standards@freebsd.org Wed Feb 21 22:14:29 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 971D5F059E5 for ; Wed, 21 Feb 2018 22:14:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 28129762E2 for ; Wed, 21 Feb 2018 22:14:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x235.google.com with SMTP id p78so3783721iod.13 for ; Wed, 21 Feb 2018 14:14:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=gU4gYF1qpfETgnItMhM2xAKe23OyQi6rDGGjyVLoC3A=; b=hNvvv21ItYmBdFJIk0EN7ir0OjTvkFu/ymmDGi4cXnlBNiNLNcBzsUF9H7kUsxuB2V U2BV5YRwRdWHoop4HIQgb3h5oZFHV3yxQRR0x/9peSe0UqQsg2p1MKXOxfjNU0C8iNuG vrTmZuC/JIzlW+lRG+x54NeuZ/6YSgayBTkkJKV7JM0QEcyaizJSEzVUQ3C7h+e5gAyJ RN/tt+chqj4HR/dovzk+NOdZo5V13ysF6O8/FjJTSWqH521aBomLY2RIETg+uVx91AMZ O0Xw7+UBQjxG1wZgLI4Ig9wtxwNxeSxrTGACauMu/vBn+jUxRHGPkt8QXUMwUO65qO7d CKDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=gU4gYF1qpfETgnItMhM2xAKe23OyQi6rDGGjyVLoC3A=; b=JLWy0VyyaM2WJ5GOG0iHMzMSZAeeLYifMb3S2sve7sPe8lUfpttjh/Ri/aK2RCGvZ2 kmjas0Y17P732WWNPxeNQvIihjDknAnxq36yTcA4Rfg9OqBYdW0ug7AcuRzShWDk2IWO BzaCDWLOjwwXp17uk0LC2GjMd+RjeksncLCeA6FvXgE7AnMOfuTvn1AP5PIkXQowdtge X/GKBjISbsr+mBN5AAVvkZxA7dHr6FKShLvPEJQl5uyVfLx3aX4vYZZCe+FoU4+dqUZ5 xe1UMhcodrzjyi/pdminOZSeOXtMReq3xf+eWxEyMfcMSC1TvU6ieZy3JwCqFkU/Rf9E r2iA== X-Gm-Message-State: APf1xPAckqn/xYEtQ3VSWUnIMOKyhpuokVR0i7LeJqjLunzRZZVyAeny 5Q7NzjUDbBPTsUOS4FOfNxcIw7PmTowe4qd+F1BJLw== X-Google-Smtp-Source: AG47ELucDLY+tvsPIvnWoHH8/PcXLY7fzvmjWhyuCscQWEJ0ncZbYeXk5vnXadMq9tZeHHG2SMYYeE5LCOZbzZwH8UQ= X-Received: by 10.107.180.83 with SMTP id d80mr6113764iof.168.1519251268439; Wed, 21 Feb 2018 14:14:28 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.201.67 with HTTP; Wed, 21 Feb 2018 14:14:27 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:18a2:a4f7:170:8dd9] In-Reply-To: References: From: Warner Losh Date: Wed, 21 Feb 2018 15:14:27 -0700 X-Google-Sender-Auth: FAA8Cp-9QH7eEuvt3tELm5oqJ9A Message-ID: Subject: Re: Using the monotonic clock in time(1)? To: Alan Somers Cc: freebsd-standards@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 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: Wed, 21 Feb 2018 22:14:29 -0000 On Wed, Feb 21, 2018 at 2:33 PM, Alan Somers wrote: > time(1) currently uses the realtime clock, which is undesirable for timing > short-lived commands while ntpd is active. I opened a review to add an > option to use the monotonic clock instead, but jilles suggested that time > should use the monotonic clock unconditionally, since that's almost always > better for measuring short durations. However, the Open Group's > specification seems to require the real time clock. What do the standards > folks think? Is the Open Group spec sufficiently ambiguous and/or wrong > that we should switch to the monotonic clock instead? > > https://reviews.freebsd.org/D14032 > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/time.html The issue with ntpd should only be the initial step. After that it steers the frequency of the base clock which affects all clocks. It should be a rare issue that the two clocks give different results. Having said that I see no issue with using a monotonic clock here. I think there's enough wiggle room in the standard to support it. It's really the only clock you can t2-t1 with and get a guaranteed to be meaningful answer. I can't imagine the OpenGroup specifies what happens over a time step the real time clock for programs timed with time. The (real) is in parens, which is not a normative form for specifying the time. I'm not a professional standards lawyer, but my amateur reading says this is a good change. Warner From owner-freebsd-standards@freebsd.org Wed Feb 21 22:22:57 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 F0842F064B2 for ; Wed, 21 Feb 2018 22:22:56 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (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 5276D7683B for ; Wed, 21 Feb 2018 22:22:56 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf0-x230.google.com with SMTP id 70so4611045lfw.2 for ; Wed, 21 Feb 2018 14:22:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=mSHjx3YIJLIM3xpstLoK7MTBtmEIGSjvtBmpizRSo00=; b=iB4qTzri/dLFgDApUxoWioK4KYJqnKZU1mPsFEfKs8Hma5UToBBfizdYkw/n3yr3Dn 5K12ymA5ATQFiJJVvEfxkjiC0pQdCpFhNEqhcVsmntDOEoKGwIZ+uwM9l7xssOwLY3iy t+LyNe0iUDSRrDk53iyv0MT1q9bX86OqCEJ3gatBH5yLTRqc6seKrez1/UFn+1Rl4D57 mYtSEqazHIIxBl9LSg2je9+yw7e+oyk1VhB+xKZX0RcfLlaf3BqFz+f5JQeE3eqUeFCc 23ZYSK2xdRW4uoOioOxR7BeNnQDXMh5hHyjV4mpg5XSgRaRoOtfdUfy4Fn7gmscZSagt 5pcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=mSHjx3YIJLIM3xpstLoK7MTBtmEIGSjvtBmpizRSo00=; b=JctI1K2a1aI9zG7vrgO+7qAwxOZNzUcRj538G9BNL8SFxLtQlBZOvFvSXftFYUpqEt 0OrX63yfp+vrPgKhPwnm7SZRo3QphEm8TG073Ds2NmdFYlAxnHBKv42Kyt//4jnyZYVh ZGsuoiR2jK/LrFYUGFEPjolqWVALtjHXevQWybeou0MuGkacTQZQoxuLLPO4376heazn mj91sV27AIBzZZ0OryvHDPQdvfANtJGUGAzt00WzLtV6/FeNpVFU2JonlreXtsfJ5aXX VY/0bf45TXKx2EPagKHcdkNDRyLrtJvghYEnl/fdRQwwf6W2JQZrVX/VvxlTzHkVrxml Q2hQ== X-Gm-Message-State: APf1xPDwBywF1CBrIljyPB3q00IdQopbogTxO01eQLJ6oq2mAICGTFTl PIdV9tv43zdBvepEQxI0HUhkUjOSXxUadg9mUr4= X-Google-Smtp-Source: AH8x2270L7Q8XSHjkuh8hnAeC4CH20an/wlR7CicJ6vX8NAoBe/aY1aJdGMhsSPJ9t+mRxkhW9dUrmiKrdE0voUC23E= X-Received: by 10.46.50.16 with SMTP id y16mr3220599ljy.53.1519251774854; Wed, 21 Feb 2018 14:22:54 -0800 (PST) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.179.30.66 with HTTP; Wed, 21 Feb 2018 14:22:54 -0800 (PST) In-Reply-To: References: From: Alan Somers Date: Wed, 21 Feb 2018 15:22:54 -0700 X-Google-Sender-Auth: FLktliqcPuzC3ZXyJEaCq6_aWyg Message-ID: Subject: Re: Using the monotonic clock in time(1)? To: Warner Losh Cc: freebsd-standards@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 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: Wed, 21 Feb 2018 22:22:57 -0000 On Wed, Feb 21, 2018 at 3:14 PM, Warner Losh wrote: > > > On Wed, Feb 21, 2018 at 2:33 PM, Alan Somers wrote: > >> time(1) currently uses the realtime clock, which is undesirable for timing >> short-lived commands while ntpd is active. I opened a review to add an >> option to use the monotonic clock instead, but jilles suggested that time >> should use the monotonic clock unconditionally, since that's almost always >> better for measuring short durations. However, the Open Group's >> specification seems to require the real time clock. What do the standards >> folks think? Is the Open Group spec sufficiently ambiguous and/or wrong >> that we should switch to the monotonic clock instead? >> >> https://reviews.freebsd.org/D14032 >> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/time.html > > > The issue with ntpd should only be the initial step. After that it steers > the frequency of the base clock which affects all clocks. It should be a > rare issue that the two clocks give different results. > > Having said that I see no issue with using a monotonic clock here. I think > there's enough wiggle room in the standard to support it. It's really the > only clock you can t2-t1 with and get a guaranteed to be meaningful answer. > I can't imagine the OpenGroup specifies what happens over a time step the > real time clock for programs timed with time. The (real) is in parens, > which is not a normative form for specifying the time. I'm not a > professional standards lawyer, but my amateur reading says this is a good > change. > > Warner > I was needlessly specific when I said "ntpd". I should've said "when some other process may change the system clock". For example, Active Directory has its own time-synchronization protocol, and at least one AD client will step the clock, rather than slew it like ntpd does. -Alan From owner-freebsd-standards@freebsd.org Wed Feb 21 22:56:56 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 B540EF08B49 for ; Wed, 21 Feb 2018 22:56:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 47D6A77B53 for ; Wed, 21 Feb 2018 22:56:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22f.google.com with SMTP id 30so3931189iog.2 for ; Wed, 21 Feb 2018 14:56:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=+Pc5Wl1M3h0T4L9G664Y22dXFxmgSyFSuQvx6doX2Zc=; b=P/paQ02tFKVGZLVxgDYTmLM+f0/EnInxZvNDKuP0T0dNGR8lvS+E4JtYyA7RpIvEAc 06tnbJQ/iiE4TvJ6Emt17O6KksOriqqH8oPBmlZtAAUM3q8+CyYQmvpwcctsRNlJHrJk f7CtzU7cqnZQaNRjs/ZD03cU12sXklF4KNAUcVOq2k7PE1glYut/YUJOLkcikF9gbHL5 m6M6zQ5hkQS64mCubbEhCWndVNk2hkS0F1qe/g9nhGLuF5dXKheaPkaO12pdP1ScksUz 8VUimdpPuPtrB1G4SuB+fOHgkkgIJ8hN8mU7EkWur4s9f9pdnXuIpHiFc6EKIFBG8GO0 +XTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=+Pc5Wl1M3h0T4L9G664Y22dXFxmgSyFSuQvx6doX2Zc=; b=KB2CUl5jJF9zdfP5LguYjnV33VSTzf72j8a1VxlPZYsEKWJ911OhVpbpKC31joS+AZ PcsbXWODfjXyNdgIkyBvsnlJADXXkCm3KXxKwjOxRs7I/44piY1iJipx6DOqCJgCCmf1 LOizeIyj76qki69Mi2MwERdQJgeVQCfhZKMbZB1B7G6i2kZA3KXZ3+f8BFvqbO09pXkK a5w6F9fepzFGZN1HL+7V1ljNJKNL6aPS5kTDQriMF8vSWl6YG1L5oX/MJd4InDGTGrUP d3eeBWlOuKmnGPOEoBbi7VMxmsl43WKI5dR6tkOhMeWCJ+YxPw80X4Bwzi9ikEfzInv+ On+w== X-Gm-Message-State: APf1xPAGmd/vSy7sn4gHMcDgDxoakhV6IwEL54aHx5Vjy3IJMlmR8iFA YD7N9PSCBM3+rM4fMQMSSxFbmNVzka3Ny7sgfNP2zw== X-Google-Smtp-Source: AG47ELtg/1NM4WCtzzOJHxFtf8IywfMn12bSh1FpEezLA8K3ZFTgAVpzCPQ8Q9CgmeCbI2M8H9al57HZSqZnkcyETb4= X-Received: by 10.107.180.83 with SMTP id d80mr6234772iof.168.1519253815522; Wed, 21 Feb 2018 14:56:55 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.201.67 with HTTP; Wed, 21 Feb 2018 14:56:54 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: References: From: Warner Losh Date: Wed, 21 Feb 2018 15:56:54 -0700 X-Google-Sender-Auth: XvS7vsa0lnCpGEOMwuskcHHxx2g Message-ID: Subject: Re: Using the monotonic clock in time(1)? To: Alan Somers Cc: freebsd-standards@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 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: Wed, 21 Feb 2018 22:56:56 -0000 On Wed, Feb 21, 2018 at 3:22 PM, Alan Somers wrote: > On Wed, Feb 21, 2018 at 3:14 PM, Warner Losh wrote: > >> >> >> On Wed, Feb 21, 2018 at 2:33 PM, Alan Somers wrote: >> >>> time(1) currently uses the realtime clock, which is undesirable for >>> timing >>> short-lived commands while ntpd is active. I opened a review to add an >>> option to use the monotonic clock instead, but jilles suggested that time >>> should use the monotonic clock unconditionally, since that's almost >>> always >>> better for measuring short durations. However, the Open Group's >>> specification seems to require the real time clock. What do the >>> standards >>> folks think? Is the Open Group spec sufficiently ambiguous and/or wrong >>> that we should switch to the monotonic clock instead? >>> >>> https://reviews.freebsd.org/D14032 >>> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/time.html >> >> >> The issue with ntpd should only be the initial step. After that it steers >> the frequency of the base clock which affects all clocks. It should be a >> rare issue that the two clocks give different results. >> >> Having said that I see no issue with using a monotonic clock here. I >> think there's enough wiggle room in the standard to support it. It's really >> the only clock you can t2-t1 with and get a guaranteed to be meaningful >> answer. I can't imagine the OpenGroup specifies what happens over a time >> step the real time clock for programs timed with time. The (real) is in >> parens, which is not a normative form for specifying the time. I'm not a >> professional standards lawyer, but my amateur reading says this is a good >> change. >> >> Warner >> > > I was needlessly specific when I said "ntpd". I should've said "when some > other process may change the system clock". For example, Active Directory > has its own time-synchronization protocol, and at least one AD client will > step the clock, rather than slew it like ntpd does. > How utterly crappy a daemon that is. Be that as it may, I'm glad to see this change since the monotonic is one of the few unix clocks you can do t2 - t1 with. It doesn't even suffer from the leap second problem that all other Unix clocks suffer from. Warner From owner-freebsd-standards@freebsd.org Thu Feb 22 10:29:05 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 DC4AFF1D2F5; Thu, 22 Feb 2018 10:29:04 +0000 (UTC) (envelope-from tijl@freebsd.org) Received: from mailrelay104.isp.belgacom.be (mailrelay104.isp.belgacom.be [195.238.20.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "relay.skynet.be", Issuer "GlobalSign Organization Validation CA - SHA256 - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2507B79B55; Thu, 22 Feb 2018 10:29:03 +0000 (UTC) (envelope-from tijl@freebsd.org) X-Belgacom-Dynamic: yes IronPort-PHdr: =?us-ascii?q?9a23=3Afq38BRdqJcbJwJEuZAPZUf42lGMj4u6mDksu8pMi?= =?us-ascii?q?zoh2WeGdxcS4Zh7h7PlgxGXEQZ/co6odzbaO6Oa4ASQp2tWoiDg6aptCVhsI24?= =?us-ascii?q?09vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6nK94iQPFRrhKAF7?= =?us-ascii?q?Ovr6GpLIj8Swyuu+54Dfbx9HiTahb75+Ngm6oRnMvcQKnIVuLbo8xAHUqXVSYe?= =?us-ascii?q?RWwm1oJVOXnxni48q74YBu/SdNtf8/7sBMSar1cbg2QrxeFzQmLns65Nb3uhnZ?= =?us-ascii?q?TAuA/WUTX2MLmRdVGQfF7RX6XpDssivms+d2xSeXMdHqQb0yRD+v9LlgRgP2hy?= =?us-ascii?q?gbNj456GDXhdJ2jKJHuxKquhhzz5fJbI2JKPZye6XQds4YS2VcRMZcTyJPDIOi?= =?us-ascii?q?YYUSDOQOP+hYoIbhqFUBtha+GQuhCP/zxjNUmnP6w6s32PkhHwHc2wwgGsoDvm?= =?us-ascii?q?rVrNX3MKcZTP64zK7PzTXYcfxW3C3y6I7Tchs8pvyMQbNwccjVyUQ0Fw3FlEuf?= =?us-ascii?q?ppL4Mj2I2OoBqW+b7/BvVe+2jWMstg9/oj+qxsg2i4nJgJoYykvD9SVk2oY6Oc?= =?us-ascii?q?O3SUBhbt6+DpRcrSaaN5F5Qs4kXmpmuz46x6UFtJKmZiQG1psqyh/FZ/CafYWF?= =?us-ascii?q?7AjvWPufLDp3gn9uZaixiAyo8Ue6z+3xTsy00FFXoSVbitTMrXUN1wDL6siAV/?= =?us-ascii?q?t94l+t2TaR2ADX7eFJOUM0mrDfK54gx74/iIATsUPZEi/qmUX2jquWel849eiv?= =?us-ascii?q?7OTneavpppqGOI9ykQHyKKMumtawAeggMwgOWXaU+fik2bDg4EH1WqtGg/I3n6?= =?us-ascii?q?XDrZzXK8oWqrSkDwJb3Ysv8xO/AC2n0NQck3kHNlVFeBefgoj1OlHOIvT4AOyx?= =?us-ascii?q?g1S2jjhk2evJPqb8DZnXKXjDirjhca5n60FA0Aoz0cxf55VMB7ECJ/LzQVPxtN?= =?us-ascii?q?3bDhAiLQO0x/3qCNp41owEWGKPBrWVP7/VsV+NtaoTJLyvY4kOpD/7N/kjr9Tj?= =?us-ascii?q?iXgkglgDNf2q2oALaXOyE/BOLECQYH6qidAERzQkpA07GdDrilnKejlUfHu3Vq?= =?us-ascii?q?QnrmUnCYCiJanZS42Hu5DH2z20SM4FLltaA0yBRC+7P76PXO0BPWfLepds?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2ARCwCOmo5a/4aF9lFcHAEBAQQBAQoBA?= =?us-ascii?q?YNPRhAQcCiPAY0DAQGCATIBY4gBjk2CFi+FCQQCAoIxVhcBAgEBAQEBAQIBaih?= =?us-ascii?q?CDgGBZyQBgkcBBTocIxALDgoJJQ8SGB4GE4oLAxkMrSKHOA2BMoITAQEBAQEBA?= =?us-ascii?q?QMBAQEBAQEdBYURhWWDLoJsRAQZh1IFpAo1CYgoiFuEfoEGk0uODEiLEiEBNoF?= =?us-ascii?q?RTTAIgn2Ed0A3AQmBSYpxAQEB?= X-IPAS-Result: =?us-ascii?q?A2ARCwCOmo5a/4aF9lFcHAEBAQQBAQoBAYNPRhAQcCiPAY0?= =?us-ascii?q?DAQGCATIBY4gBjk2CFi+FCQQCAoIxVhcBAgEBAQEBAQIBaihCDgGBZyQBgkcBB?= =?us-ascii?q?TocIxALDgoJJQ8SGB4GE4oLAxkMrSKHOA2BMoITAQEBAQEBAQMBAQEBAQEdBYU?= =?us-ascii?q?RhWWDLoJsRAQZh1IFpAo1CYgoiFuEfoEGk0uODEiLEiEBNoFRTTAIgn2Ed0A3A?= =?us-ascii?q?QmBSYpxAQEB?= Received: from 134.133-246-81.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([81.246.133.134]) by relay.skynet.be with ESMTP; 22 Feb 2018 11:27:54 +0100 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.15.2/8.15.2) with ESMTP id w1MARqqA036862; Thu, 22 Feb 2018 11:27:53 +0100 (CET) (envelope-from tijl@FreeBSD.org) Date: Thu, 22 Feb 2018 11:27:52 +0100 From: Tijl Coosemans To: Konstantin Belousov Cc: Eitan Adler , Kevin Lo , FreeBSD Standards , FreeBSD Hackers Subject: Re: Marking select(2) as restrict Message-ID: <20180222112752.10da7e51@kalimero.tijl.coosemans.org> In-Reply-To: <20180221104400.GU94212@kib.kiev.ua> References: <20180221032247.GA81670@ns.kevlo.org> <20180221104400.GU94212@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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:29:05 -0000 On Wed, 21 Feb 2018 12:44:00 +0200 Konstantin Belousov wrote: > On Tue, Feb 20, 2018 at 10:14:05PM -0800, Eitan Adler wrote: >> On 20 February 2018 at 21:19, Warner Losh wrote: >>> Once upon a time, this would break a lot of code. Perhaps times have >>> changed. >> >> I've seen very little code that this would break though some of it >> certainly exists. > You certainly seen very little code, but the question was about the > existed code. FWIW, it seems that glibc uses restrict since 2000 so there's unlikely to be much fallout: https://sourceware.org/git/?p=glibc.git;a=blob;f=misc/sys/select.h https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=98cbe360d947b59e7a5eda068581f4cfeb4b99b3 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 From owner-freebsd-standards@freebsd.org Thu Feb 22 10:56:21 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 E11C1F217A9; Thu, 22 Feb 2018 10:56:21 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 596C27AFC4; Thu, 22 Feb 2018 10:56:21 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w1MAu905013493 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 22 Feb 2018 12:56:12 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w1MAu905013493 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w1MAu8Bw013492; Thu, 22 Feb 2018 12:56:08 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 22 Feb 2018 12:56:08 +0200 From: Konstantin Belousov To: Tijl Coosemans Cc: Eitan Adler , Kevin Lo , FreeBSD Standards , FreeBSD Hackers Subject: Re: Marking select(2) as restrict Message-ID: <20180222105608.GE94212@kib.kiev.ua> References: <20180221032247.GA81670@ns.kevlo.org> <20180221104400.GU94212@kib.kiev.ua> <20180222112752.10da7e51@kalimero.tijl.coosemans.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180222112752.10da7e51@kalimero.tijl.coosemans.org> User-Agent: Mutt/1.9.3 (2018-01-21) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home 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:22 -0000 On Thu, Feb 22, 2018 at 11:27:52AM +0100, Tijl Coosemans wrote: > On Wed, 21 Feb 2018 12:44:00 +0200 Konstantin Belousov wrote: > > On Tue, Feb 20, 2018 at 10:14:05PM -0800, Eitan Adler wrote: > >> On 20 February 2018 at 21:19, Warner Losh wrote: > >>> Once upon a time, this would break a lot of code. Perhaps times have > >>> changed. > >> > >> I've seen very little code that this would break though some of it > >> certainly exists. > > You certainly seen very little code, but the question was about the > > existed code. > > FWIW, it seems that glibc uses restrict since 2000 so there's unlikely to > be much fallout: > https://sourceware.org/git/?p=glibc.git;a=blob;f=misc/sys/select.h > https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=98cbe360d947b59e7a5eda068581f4cfeb4b99b3 Clearly, nobody knowns. At least, glibc is used with gcc compilation, not with clang. Consider the recently changed devd code: select(n + 1, &fd, &fd, &fd); There, compiler can see that restrict is applied to arguments which are given same values. Since this leads to the self-contradicting statement fd != fd which cannot be true, compliler in its optimizing wisdom can assume that the code is never executing and remove it. I do not know whether clang actually makes such transformation, but it does not sound unfeasible looking at its other advances. From owner-freebsd-standards@freebsd.org Thu Feb 22 14:31:20 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 5238CF089CE for ; Thu, 22 Feb 2018 14:31:20 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail109.syd.optusnet.com.au (mail109.syd.optusnet.com.au [211.29.132.80]) by mx1.freebsd.org (Postfix) with ESMTP id B8DA086216; Thu, 22 Feb 2018 14:31:19 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from [192.168.0.102] (c110-21-101-228.carlnfd1.nsw.optusnet.com.au [110.21.101.228]) by mail109.syd.optusnet.com.au (Postfix) with ESMTPS id E666AD69241; Fri, 23 Feb 2018 00:04:16 +1100 (AEDT) Date: Fri, 23 Feb 2018 00:04:16 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Alan Somers cc: freebsd-standards@freebsd.org Subject: Re: Using the monotonic clock in time(1)? In-Reply-To: Message-ID: <20180222222839.P2892@besplex.bde.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=cIaQihWN c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=kj9zAlcOel0A:10 a=6I5d2MoRAAAA:8 a=uZvujYp8AAAA:8 a=8RthIaNpeVom1orCaKcA:9 a=AE_QS5vz26Z8U8AU:21 a=ACPfsa0X82TchGwt:21 a=CjuIK1q_8ugA:10 a=sUulJ21unHkA:10 a=IjZwj45LgO3ly-622nXo:22 a=SLzB8X_8jTLwj6mN0q5r:22 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 14:31:20 -0000 On Wed, 21 Feb 2018, Alan Somers wrote: > time(1) currently uses the realtime clock, which is undesirable for timing > short-lived commands while ntpd is active. I opened a review to add an > option to use the monotonic clock instead, but jilles suggested that time > should use the monotonic clock unconditionally, since that's almost always > better for measuring short durations. However, the Open Group's > specification seems to require the real time clock. What do the standards > folks think? Is the Open Group spec sufficiently ambiguous and/or wrong > that we should switch to the monotonic clock instead? > > https://reviews.freebsd.org/D14032 > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/time.html I think it really does mean the CLOCK_REALTIME for the real time. time(1) and syscalls involving times had no alternative to using the real time before CLOCK_MONOTONIC existed, and changing them to use another clock id would be incompatible. POSIX is more careful about this for sleep() and nanonsleep(). It specifies using CLOCK_REALTIME for old sleep functions and adds clock_nanosleep() to allow sleeping on CLOCK_MONOTONIC and possibly other clock ids. This was broken in FreeBSD until recently. FreeBSD didn't have clock_nanosleep(), and its nanosleep() slept on CLOCK_MONOTONIC without documenting this, but claimed conformance with POSIX.1-1993 which specifies CLOCK_REALTIME. I think itimers are still broken. POSIX is not so careful for them. In the 2001 version, it specifies that ITIMER_REAL decrements in real time, whatever that is. realitimexpire() does sleep on real time in 4.4BSD-Lite, but FreeBSD changed it to sleep on a monotonic time (the fuzzy one returned by getmicrouptime()) in FreeBSD-3 or earlier. realitimexpire() now sleeps on the non-fuzzy monotonic time returned by microuptime(). POSIX.1-1993 has better (except more complicated) APIs than the itimer ones. These move the bugs to applications by making the timer id a parameter. The 2007 version of POSIX still says "real time" for ITIMER_REAL. However, both versions have a whole section 3.307 to give a not so good specification of "Real Time". This doesn't mention CLOCK_REALTIME, but says "Time measured as total units elapsed by the system clock...". It is clear that there is only 1 system clock, and it would be strange if the one used to measure real times is not CLOCK_REALTIME.s Kernel timeouts are still broken. Always using the monotonic clock for them would be correct if it were documented and the monotonic clock worked. However, the monotonic clock doesn't advance while the system is suspended, and timeouts based on it are extended by the length of the suspension. POSIX doesn't allow this. It requires the monotonic clock to measure time (whatever) that is since some fixed time in the past, but FreeBSD acts as if this point varies, and the implementation is essentially to vary it. Steps of CLOCK_REALTIME also vary it. "sysctl kern.boottime" shows this point and its changes. Utilities like w show the monotonic time but claim to show the uptime. It really is the uptime not counting suspended time. After nanosleep() was fixed, "time sleep 10" has a chance of working across leap seconds adjustments, clock steps, and short suspensions. It should sleep for 10+ seconds according time time(), even when the physical time advanced by a different amount (least illegitimately, by 9 or 11 seconds for a leap seconds adjustment; clock steps shouldn't be allowed; and for suspensions the physical time should be 10 seconds). If you change time(1) to show the monotonic time, this would break again, especially across suspensions since the monotonic time is broken across them. The breakage would be small after fixing the monotonic time and not allowing steps. The only difference is for leap seconds. It is unclear what time is or what different clocks measure. Clocks can't measure physical time (whatever that is) exactly and the implementation has to slew them so that they don't drift too far from the absolute physical time. FreeBSD slews the real and monotonic times at the same rate and does illegal steps to make some things work and break others. A better implementation would slew these clocks at different rates, as needed for them to be as equal as possible after adjusting for their starting times. The only long-term difference should be for leap seconds. This is a POSIX bug. POSIX requires misrepresentation of leap seconds by its over-specification of the representation of time_t. For example, suppose both times are the same after the adjustment, but are physically wrong, and someone fixes this by stepping CLOCK_REALTIME. CLOCK_MONOTONIC should not be stepped, but should be slewed at a different rate. OTOH, if the clocks are the same and a leap second adjusment is applied, then CLOCK_REALTIME must be stepped, but this adjustment is not physical so it should never be applied to CLOCK_MONOTONIC. Another way of looking at this is that CLOCK_MONOTONIC should be as close as possible to the physical time since the fixed time in the past. It may drift away, but then it should be slowly slewed back. BTW, I recently found that time(1) [-l] is very deficient for measuring makeworld benchmarks because it doesn't understand system time for other threads or interrupt time. I already knew that, but didn't notice how large the unaccounted-for time has become due to having more CPUs and things like task queues to do the work. The usr/sys split for a single thread is also very inaccurate for short-lived threads. stathz is still 128 and many cc threads and subthreads can be run in 1/128 seconds. time(1) [-l] on a large build adds up tiny values in struct rusage for many children and the errors don't compensate each other very well. struct rusage is also missing important information like the number of syscalls. init(8) inherits the all the child rusages but there is no API for seeing init's rusage. For a large benchmark on an otherwise-idle system, it works well to use global counters read using sysctl. kern.cp_time is just as accurate as time(1) for the real time given by the sum of the counters (divided by stathz) and better for everything else. It already gives monotonic time. From owner-freebsd-standards@freebsd.org Thu Feb 22 14:43:13 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 92CAEF09F7C for ; Thu, 22 Feb 2018 14:43:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (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 22E8686FE7 for ; Thu, 22 Feb 2018 14:43:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x235.google.com with SMTP id o9so6482977itc.1 for ; Thu, 22 Feb 2018 06:43:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=EM2KxAZL0XlKpUghAGAK4YI/6AP1FycMznJ54Q1qHyw=; b=W6+hiLqGilN/tl3OZ39a7jYcLDp1bc+racuYui2dIe19Ps+09R0Rk8/CdAbuLiqzWZ YSqcAgEgsrbt39ZhX2Y7G/8LrdooJamp9/1Fi52y2emqLTugVZnhzLqmXqyLsly2TOrw QFbvY/V5GWxpetV4krypRC4zi5YoXM6B6F6yqLb2+t1zKChS9cpn/Cq1czMUn3w7RNAt CMTaV1DOtQzEGDsX4m5ut/EigUds7wGviPm3MB2fKOh/gIxc7XiOMvdaZ1rm6mLmaBt4 +isK1MIYJVVeewlqOUrLUrGc7WRgPVKhKXWWTL1GbZjfV4Yk3ZxqH+hBFyHp9OYJo2fv VZGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=EM2KxAZL0XlKpUghAGAK4YI/6AP1FycMznJ54Q1qHyw=; b=Dc1CK36a5nsUbKXOV+M3vXYGQAAkz0sGw1WJwWCywDWCPnSrtiV4PDAOJDhTrCoczh 9V9TIobC2qu27BbOIRGakIOYNmckVNyPSORzxawG5Jx/A47HqjhoyS0nyOtnwGlrQlW0 dsExKFJxdayJt/cd1AooA3jtPIDwSZN5UcbDpuazQTmrIPUq89N9djp4/BgIzWRcAeWg 1EMnUlFf99STjjalLNxPj1YyfES4It/kk9VsgicKnQ6ZOz+ONsZs0nUzNiC2/tq9HPD8 teZ6PY5foiREBBCt4riPQxB2/Ty0nrLzVY4VraLEi6J/iZ9WE52Alv81QVhsYINR6bQx aSKg== X-Gm-Message-State: APf1xPBhFksfr93jjRfPJU0cbwTx+zni8FVjYEuPHUx4OXYQ4ZRcVFat AleFg+FAI+pfVkm0mDCb8p5vx7rhjPRJXwlDrBR3mw== X-Google-Smtp-Source: AH8x225fxLzIL+FiRRoRNva9EsVMydE2iVl/B3mbsn/qp0AImMFXNnP/Nsz0ehtl7jb2NhviGGqGFiFnVBIGOG+rQvA= X-Received: by 10.36.6.70 with SMTP id 67mr1664189itv.57.1519310592351; Thu, 22 Feb 2018 06:43:12 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.201.67 with HTTP; Thu, 22 Feb 2018 06:43:11 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:18a2:a4f7:170:8dd9] In-Reply-To: <20180222105608.GE94212@kib.kiev.ua> References: <20180221032247.GA81670@ns.kevlo.org> <20180221104400.GU94212@kib.kiev.ua> <20180222112752.10da7e51@kalimero.tijl.coosemans.org> <20180222105608.GE94212@kib.kiev.ua> From: Warner Losh Date: Thu, 22 Feb 2018 07:43:11 -0700 X-Google-Sender-Auth: iQ1hcDK5R_Eedt1-bvTRbCjG1nA Message-ID: Subject: Re: Marking select(2) as restrict To: Konstantin Belousov Cc: Tijl Coosemans , FreeBSD Standards , FreeBSD Hackers , Kevin Lo Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 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 14:43:13 -0000 On Thu, Feb 22, 2018 at 3:56 AM, Konstantin Belousov wrote: > On Thu, Feb 22, 2018 at 11:27:52AM +0100, Tijl Coosemans wrote: > > On Wed, 21 Feb 2018 12:44:00 +0200 Konstantin Belousov < > kostikbel@gmail.com> wrote: > > > On Tue, Feb 20, 2018 at 10:14:05PM -0800, Eitan Adler wrote: > > >> On 20 February 2018 at 21:19, Warner Losh wrote: > > >>> Once upon a time, this would break a lot of code. Perhaps times have > > >>> changed. > > >> > > >> I've seen very little code that this would break though some of it > > >> certainly exists. > > > You certainly seen very little code, but the question was about the > > > existed code. > > > > FWIW, it seems that glibc uses restrict since 2000 so there's unlikely to > > be much fallout: > > https://sourceware.org/git/?p=glibc.git;a=blob;f=misc/sys/select.h > > https://sourceware.org/git/?p=glibc.git;a=commitdiff;h= > 98cbe360d947b59e7a5eda068581f4cfeb4b99b3 > > Clearly, nobody knowns. At least, glibc is used with gcc compilation, not > with clang. > > Consider the recently changed devd code: > select(n + 1, &fd, &fd, &fd); > There, compiler can see that restrict is applied to arguments which are > given same values. Since this leads to the self-contradicting statement > fd != fd > which cannot be true, compliler in its optimizing wisdom can assume that > the code is never executing and remove it. I do not know whether clang > actually makes such transformation, but it does not sound unfeasible > looking at its other advances. > If the compilers affirmatively fails when this happens, then the exp run will catch this stuff. If it doesn't, or just gives a warning, it likely will not. Absent that, nobody can say with certainty this change won't break anything. Warner From owner-freebsd-standards@freebsd.org Thu Feb 22 19:42:41 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 D9B11F25090 for ; Thu, 22 Feb 2018 19:42:40 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (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 79C4074E28 for ; Thu, 22 Feb 2018 19:42:40 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-qt0-x22c.google.com with SMTP id a9so7773841qtj.8 for ; Thu, 22 Feb 2018 11:42:40 -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=Az/Y2jgP1/LWb2ojSWHIvH6X9NYXxZaprxLuWwWLc3M=; b=ttm2Dsq5lacKRgNFstSklTiH1ReurUahNm0XU7b/7uiVbdPzO1ZvaI0ArGyYlOrfYb dGkHFree+eiuBwJH+J25jSmiwuuHhycsVgBMXcI7v+Im/WF6auv6tEJBVtD1f/nuNPo2 1gNLcybYpovRPdnqOncoBvj5emNoDLBwM+iyo= 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=Az/Y2jgP1/LWb2ojSWHIvH6X9NYXxZaprxLuWwWLc3M=; b=rR2a5kBdLgt8cwQgcLCDnYQ1bKClELSHYXmY9YTZ/YHlQszs0bXhrh0Usddb6bFvnZ 3Xag9ix82M8tm0aA3Mxtf8dfZubSQoa4JeDEXUbFZxXsgnF4auVg02yXhFFQYu/OqVPk O3glIAUElBvkCw7HaY5bLYc58WUAXyOAisPLAea49qegCqTie5C69/DSkU6OcHpFyd7b foxIJ5y1WuyquPO00TDgRLxRVZutcltAc/Hei9aF/mnXmXUIhBTP9u9pqcZ6wX3E2wFg xg1o+Cx6nuho+xAqCKwqFcTSNMCmVjmVAUksI2M2tMBB5kRzGVlXn4FA+aixQVqmnb1Z 2Gmw== X-Gm-Message-State: APf1xPAgtr9ZWnsWpUsxZbD2hbsEpO+o3pky+YbOdoyHT3oZE7fHYMmG 0c6r81GI4ftZWx4ZlFZF0gvpYdJZAvSGbGhDSO2ECQ== X-Google-Smtp-Source: AH8x224/5zKCCC9mN3j1sS3nbvIukj61GaIiKTYwJ9Gz2CGcocIIoJRGg3JJi2ijbRBDl9a34gJd2HC0z4HEbKwM50c= X-Received: by 10.237.55.33 with SMTP id i30mr13019262qtb.202.1519328559888; Thu, 22 Feb 2018 11:42:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.25.173 with HTTP; Thu, 22 Feb 2018 11:42:09 -0800 (PST) In-Reply-To: References: <20180221032247.GA81670@ns.kevlo.org> <20180221104400.GU94212@kib.kiev.ua> <20180222112752.10da7e51@kalimero.tijl.coosemans.org> <20180222105608.GE94212@kib.kiev.ua> From: Eitan Adler Date: Thu, 22 Feb 2018 11:42:09 -0800 Message-ID: Subject: Re: Marking select(2) as restrict To: Warner Losh Cc: Konstantin Belousov , FreeBSD Hackers , Tijl Coosemans , FreeBSD Standards , Kevin Lo 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 19:42:41 -0000 On 22 February 2018 at 06:43, Warner Losh wrote: > On Thu, Feb 22, 2018 at 3:56 AM, Konstantin Belousov > wrote: > >> On Thu, Feb 22, 2018 at 11:27:52AM +0100, Tijl Coosemans wrote: >> > On Wed, 21 Feb 2018 12:44:00 +0200 Konstantin Belousov < >> kostikbel@gmail.com> wrote: >> > > On Tue, Feb 20, 2018 at 10:14:05PM -0800, Eitan Adler wrote: >> > >> On 20 February 2018 at 21:19, Warner Losh wrote: >> > >>> Once upon a time, this would break a lot of code. Perhaps times have >> > >>> changed. >> > >> >> > >> I've seen very little code that this would break though some of it >> > >> certainly exists. >> > > You certainly seen very little code, but the question was about the >> > > existed code. >> > >> > FWIW, it seems that glibc uses restrict since 2000 so there's unlikely to >> > be much fallout: >> > https://sourceware.org/git/?p=glibc.git;a=blob;f=misc/sys/select.h >> > https://sourceware.org/git/?p=glibc.git;a=commitdiff;h= >> 98cbe360d947b59e7a5eda068581f4cfeb4b99b3 >> >> Clearly, nobody knowns. At least, glibc is used with gcc compilation, not >> with clang. >> >> Consider the recently changed devd code: >> select(n + 1, &fd, &fd, &fd); >> There, compiler can see that restrict is applied to arguments which are >> given same values. Since this leads to the self-contradicting statement >> fd != fd >> which cannot be true, compliler in its optimizing wisdom can assume that >> the code is never executing and remove it. I do not know whether clang >> actually makes such transformation, but it does not sound unfeasible >> looking at its other advances. >> > > If the compilers affirmatively fails when this happens Compilers cannot fail since errors are only detectable at runtime. The value of the exp-run is (a) ensuring that we don't break prototypes of some applications (b) exercising the applications as much as we can -- Eitan Adler From owner-freebsd-standards@freebsd.org Thu Feb 22 20:04:53 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 EB7ECF26DE3; Thu, 22 Feb 2018 20:04:52 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-io0-f175.google.com (mail-io0-f175.google.com [209.85.223.175]) (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 818AB76E07; Thu, 22 Feb 2018 20:04:52 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-io0-f175.google.com with SMTP id l12so7302895ioc.10; Thu, 22 Feb 2018 12:04:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=cDdwIlb6TKmMvF/a/5buQpO0bZDmkrCbzeqjh8+WVTo=; b=WOY8ZT+atj4TFeVEPCk2byzESI8UKfMM34Gh9cSJB/7SSfyHKSdvzHiL9KHm4iRZMw USDCjpYSEfimKnrgTNwXZUAl5MITjXeX2zssNkP1YP54+CpdTXi539Z29U6tOWdBlibe 9kN6/8ynAHKzOMIvcrLByhNNyA90//iWKfVOVz5TZ5sfoPv5pTah8tfh5D8/utThBh46 2xjwaGA+fJ5EjTgTkG6yLyfMgkpC8lmhT4Ljl3ntIUcJgWZ9oqOJf71kPa5bM9tQGT/E o69+xJbtajSk/+DVFlOMWfGahXRqTJuU71pPL0URgQRoQ4N7LjUW1Ijnf0Jnk6+JH9I1 +tkw== X-Gm-Message-State: APf1xPCWt/1AF0zTGeruvzboKccuhfdwQQsUJdj0h/JOpwx/WmIfkcY8 6AJj66+iJuSJqdjgF2vqr9vY/Df8 X-Google-Smtp-Source: AH8x2262SBVRPzM88oE1/oeQvF5pbd6aD9Dq8rzDc6CFQydrtNBl1ILcCk+UJu2ZF8YbV8xv9R60Vw== X-Received: by 10.107.6.139 with SMTP id f11mr7431492ioi.23.1519329886288; Thu, 22 Feb 2018 12:04:46 -0800 (PST) Received: from mail-io0-f177.google.com (mail-io0-f177.google.com. [209.85.223.177]) by smtp.gmail.com with ESMTPSA id 30sm445350iop.73.2018.02.22.12.04.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Feb 2018 12:04:46 -0800 (PST) Received: by mail-io0-f177.google.com with SMTP id v6so6191091iog.7; Thu, 22 Feb 2018 12:04:46 -0800 (PST) X-Received: by 10.107.41.16 with SMTP id p16mr10348722iop.173.1519329886009; Thu, 22 Feb 2018 12:04:46 -0800 (PST) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 10.2.30.149 with HTTP; Thu, 22 Feb 2018 12:04:45 -0800 (PST) In-Reply-To: References: <20180221032247.GA81670@ns.kevlo.org> <20180221104400.GU94212@kib.kiev.ua> <20180222112752.10da7e51@kalimero.tijl.coosemans.org> <20180222105608.GE94212@kib.kiev.ua> From: Conrad Meyer Date: Thu, 22 Feb 2018 12:04:45 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Marking select(2) as restrict To: Eitan Adler Cc: FreeBSD Hackers , 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 20:04:53 -0000 On Thu, Feb 22, 2018 at 11:42 AM, Eitan Adler wrote: > On 22 February 2018 at 06:43, Warner Losh wrote: >> If the compilers affirmatively fails when this happens > > Compilers cannot fail since errors are only detectable at runtime. This is simply not true. *Some* instances of this error could only be detected at run time, but compilers can and do perform some kinds of static analysis for warning/error purposes and for optimization. In the extremely common case where fdsets are local or global variables, the compiler could easily detect when the same pointer is passed multiple times. If we're unlucky, it produces no warning and "optimizes" the undefined behavior into something awful. In my local testing, neither Clang nor GCC6 produces any error or warning for this, which is disappointing. From owner-freebsd-standards@freebsd.org Thu Feb 22 21:10:55 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 1CF1AF01386 for ; Thu, 22 Feb 2018 21:10:55 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 AE046798CB for ; Thu, 22 Feb 2018 21:10:54 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-qt0-x22f.google.com with SMTP id d8so8142318qtm.0 for ; Thu, 22 Feb 2018 13:10:54 -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=yr7jqfdI29yCeaPTLGpIgNIo3sHlEa2eW4pyEEz+ydg=; b=o5Udjgm9WO7gwmen0OWMpKUckYMP4mBFsPlmWDhChlsQJDPiwGumLtT09H6dxkjyje TlULmr+PdfSMxa3QTUmGlaLZ+C+7ISx/7gBVOTYB9BBDZ+cX5cz5hLHP7agETz9qldc1 ZSlAZ00m++TVOoI5gLPTDtqvMKHVtv+eHO/yI= 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=yr7jqfdI29yCeaPTLGpIgNIo3sHlEa2eW4pyEEz+ydg=; b=q9mAdtaveqeNbsnwwFpFpyOC2p6Knq8he4/Pw3G+fT/8F6pBflaqbbD5hHG+QLA5Ur Nlu2iNM+yw4QpFkmateslffZzYTHOOchjLIJeHdnpPYQo+lhoaw+wwKKAg/xdab6ZnT9 zNGFXHbQirHHsblfgpQ2uXMpAxP8ldqilescZ9z/Ff0w0d+Y4W2H0w2ZUrdFzs5fJeEU FIqbtPuwyaI3ha1v8hP/J8rypIjOh64kMcZ/hQv3s540Ej5bU2w4KDvqMfmQUGZeQkOW 1sHvevulDJMHbqVTr5+PKUfLo8XsXBZIwN9lXJJru1NtOxSjyjAwQy6nzVHi+D9kZqRh XhfA== X-Gm-Message-State: APf1xPBOuM/pE7cajG13lTwLpttk/SGAxAaVMJP2KyzSrm3X0wqqWVRn xpHvLK0C5abQcBQZSNKDcABMUd7xmMk4af6hTkRyiw== X-Google-Smtp-Source: AH8x227lftP2q90KblKwH8ZT41aMmq309Wiqgn7+X25bkcMp8WnyvHLFI/yUl2RlWnRL7+tM9K0pY4myd/9zwIDI3y4= X-Received: by 10.200.62.1 with SMTP id z1mr12714198qtf.218.1519333854152; Thu, 22 Feb 2018 13:10:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.25.173 with HTTP; Thu, 22 Feb 2018 13:10:23 -0800 (PST) In-Reply-To: References: <20180221032247.GA81670@ns.kevlo.org> <20180221104400.GU94212@kib.kiev.ua> <20180222112752.10da7e51@kalimero.tijl.coosemans.org> <20180222105608.GE94212@kib.kiev.ua> From: Eitan Adler Date: Thu, 22 Feb 2018 13:10:23 -0800 Message-ID: Subject: Re: Marking select(2) as restrict To: cem@freebsd.org Cc: FreeBSD Hackers , 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 21:10:55 -0000 On 22 February 2018 at 12:04, Conrad Meyer wrote: > > In my local testing, neither Clang nor GCC6 produces any error or > warning for this, which is disappointing. I forget the exact version but gcc produces this warning: restrict.c:10:6: warning: passing argument 1 to restrict-qualified parameter aliases with argument 2 [-Wrestrict] meh(&a, &a); -- Eitan Adler From owner-freebsd-standards@freebsd.org Thu Feb 22 21:27:48 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 96654F0260D for ; Thu, 22 Feb 2018 21:27:48 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mailout.stack.nl (mailout05.stack.nl [IPv6:2001:610:1108:5010::202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.stack.nl", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3321B7A283 for ; Thu, 22 Feb 2018 21:27:48 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from toad2.stack.nl (toad2.stack.nl [IPv6:2001:610:1108:5010::161]) by mailout.stack.nl (Postfix) with ESMTP id 95A2B33; Thu, 22 Feb 2018 22:27:46 +0100 (CET) Received: by toad2.stack.nl (Postfix, from userid 1677) id 915E9892DB; Thu, 22 Feb 2018 22:27:46 +0100 (CET) Date: Thu, 22 Feb 2018 22:27:46 +0100 From: Jilles Tjoelker To: Garrett Wollman Cc: Konstantin Belousov , freebsd-standards@freebsd.org Subject: Re: Marking select(2) as restrict Message-ID: <20180222212746.GB58772@stack.nl> 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> <20180221201002.GC94212@kib.kiev.ua> <23181.54825.511195.393054@khavrinen.csail.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23181.54825.511195.393054@khavrinen.csail.mit.edu> User-Agent: Mutt/1.8.0 (2017-02-23) 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 21:27:48 -0000 On Wed, Feb 21, 2018 at 03:27:21PM -0500, Garrett Wollman wrote: > < said: > > Undefined != broken, whatever some compiler vendors try to bluff. > No, undefined behavior means the application is wrong. Literally > anything may happen; the compiler does not enter into it. The > compiler is not involved when you free() a pointer into the stack, or > pass a null pointer into a library routine that unconditionally > dereferences it, or update a string literal; nor is it involved when > you pass pointers that alias to a library routine that expects them to > point to different objects. > In the particular case of select(), there are no guarantees as to the > order in which the fd_set objects pointed to by readfds, writefds, and > exceptfds will be updated, so applications which alias them are > clearly wrong and have been since this interface was introduced in > 4.2BSD. They are wrong, but get away with it if they do not care about the value stored into the fd_set object. Furthermore, adding or removing a restrict qualifier on a parameter does not make the function types incompatible (just like adding or removing a const or volatile qualifier on a parameter; but those are generally used behind a pointer which does make the function type incompatible). Therefore, it would be quite subtle for a missing restrict qualifier to break a build. Although the restrict qualifier imposes restrictions on the pointers the caller can pass, undefined behaviour only results when the callee dereferences them in disallowed ways (some compilers have bugs that make them assume the pointers differ even when never dereferenced for writing). Per the C standard, when the compiler sees aliasing pointers being passed as restrict pointers to an unknown function, it will have to assume the callee only dereferences them in permitted ways (such as not at all, only one of them or only for reading) and can therefore not optimize anything. A blog post about -Wrestrict (which was added in GCC 7) at http://excursionsingcc.blogspot.nl/2016/12/wrestrict.html confirms that the warning can emit false positives. The actual implementation of select() in libc only passes along its arguments to code the compiler cannot see. Therefore, this cannot be optimized either. -- Jilles Tjoelker From owner-freebsd-standards@freebsd.org Fri Feb 23 07:26:58 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 4EAC8F0282A for ; Fri, 23 Feb 2018 07:26:58 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-yb0-x241.google.com (mail-yb0-x241.google.com [IPv6:2607:f8b0:4002:c09::241]) (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 E694F70D63 for ; Fri, 23 Feb 2018 07:26:57 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-yb0-x241.google.com with SMTP id i15-v6so2583208ybg.7 for ; Thu, 22 Feb 2018 23:26:57 -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=ZJlc/ID3b9plARXExP9N8fjhcKCjxqWK/aRglZ8blVs=; b=IU/jhxAJQkEaYiDG79OWT1dRIDp/8PUAjQ7ZMfD0VJ9h0Rxl1wghdX4c5eQwAQ8hg8 rPxv9s6v9/1zce8lT2Zg7hEmytW5ZEFJM1k4RMFBEy37gv1oBKWkvAx5vKIyOHm9Lt3R KQHj8BrULvNzADJOgUdt+ypl1TnQhZuLezApw= 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=ZJlc/ID3b9plARXExP9N8fjhcKCjxqWK/aRglZ8blVs=; b=tHlYDlRc88XJNI4ZZDEUfZo+Qh5KpZzOLof4Ubky4OeymROy8z/WKGTbZyjblSS8Ji UL7iVRluOi2XF7dPBYHhOV7fGGEr4g+Xg/o6CRmmAI1yb7RV4hT+fcSwjEELrv6fqL4b 0Q6Vk3DdO47UQUGyWelySl1/+iJ9jGfbeZwysaBkG+KQ+fBr/jHVTE5EMdUqeg4PTL68 brBNGs5/D+VzCvgKq/WGTURlrFML3POtiOx28Wq0KkvKgNRHnNMGJVDYkwRjHgebdsDJ povpKcnX9rXuuNeltVm08Mi/On11k9oSS6gh1q0w18qqzPHumyRgy+olD1qEeAw77eoy AdVg== X-Gm-Message-State: APf1xPC2cDW0z2OpYZUvccjPW3f3a4Sw0HrKFRT5/RJJazAhA3YxMSuN l//0iWeOqfqv+nSYqYzKoXLadrGphtxtlFDHyOlcxQ== X-Google-Smtp-Source: AG47ELvm0RdhtGNq8kkC89HQNc31jvBUPPVT2NoSvuOM0tDOEVVZq5h/Hqi0kOp5lZRvnelB3CT4K20rKQDc/KAcLqY= X-Received: by 2002:a25:7b06:: with SMTP id w6-v6mr372760ybc.69.1519370816680; Thu, 22 Feb 2018 23:26:56 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a25:dfcb:0:0:0:0:0 with HTTP; Thu, 22 Feb 2018 23:26:26 -0800 (PST) In-Reply-To: <20180222212746.GB58772@stack.nl> 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> <20180221201002.GC94212@kib.kiev.ua> <23181.54825.511195.393054@khavrinen.csail.mit.edu> <20180222212746.GB58772@stack.nl> From: Eitan Adler Date: Thu, 22 Feb 2018 23:26:26 -0800 Message-ID: Subject: Re: Marking select(2) as restrict To: Jilles Tjoelker Cc: Garrett Wollman , 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: Fri, 23 Feb 2018 07:26:58 -0000 On 22 February 2018 at 13:27, Jilles Tjoelker wrote: > On Wed, Feb 21, 2018 at 03:27:21PM -0500, Garrett Wollman wrote: >> < said: ... FWIW glibc: already done - https://github.com/bminor/glibc/blob/master/misc/sys/select.h#L101 openbsd: already done https://github.com/openbsd/src/blob/master/sys/sys/select.h#L128 dragonflyBSD: alredy done: https://github.com/dragonflybsd/dragonflybsd/blob/master/sys/sys/select.h#L50 netbsd: already done: https://github.com/NetBSD/src/blob/trunk/sys/sys/select.h#L69 The patch that started this thread was incomplete, as it didn't include the timeval but I'll have an updated version in a phab soon. -- Eitan Adler From owner-freebsd-standards@freebsd.org Sat Feb 24 18:35:55 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 5513FF00BF9 for ; Sat, 24 Feb 2018 18:35:55 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002:c09::22e]) (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 E72E7709B8 for ; Sat, 24 Feb 2018 18:35:54 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-yb0-x22e.google.com with SMTP id u5-v6so2754650ybf.4 for ; Sat, 24 Feb 2018 10:35:54 -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=uY7mq37ngYgaBwjpjHzIRQqjZoOUrRCm+t8ntrrh0ok=; b=qU5QqdQrV1lNzAkwtDm1/7s5QzuSWkmXWrhdQqg6XAuM3TOP4IRewg3DoZvyNdXmYY Q2eBxujiiCfsaRslP/xB40ull6XaTGAnkNG6J1owyAspt+cBgGcj+VVr3sF2x05c3nF4 0GKC2LUPqcROo38LMHKjwCK/C/gAXrYJs9WGs= 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=uY7mq37ngYgaBwjpjHzIRQqjZoOUrRCm+t8ntrrh0ok=; b=tAf9iO8rIHtO+uD6lgLLc5/mOMhSveiCGwldOl/Qh+nogwNlZUhAaMzua12sk2kNzp 7ZSi/AR1l9dMOabq+W4wPYSi68+ZJpbdi3hfzv1xSwDurR2GRg2P6MvDDDT9qkHXpDdK zIKBJEEV/hPyhJYCEtwBdXdWjcZJ/lCI+pIsoHX3UgH8bY8QLiW3rAWnCzfz7k/6Ooeo LtFbuhE/tSbElq9L8m/ozZBh+GRNjaIaP8MnGcW1R0p04AMv/mqa1QhHEKyY/1z8PG3P s3I2l/VU+cHBEoai26BgXe+9B2yRtdsbE4bidG9Q6SHIelt1yINJ09/td5G7kUFXoDRa wX2w== X-Gm-Message-State: APf1xPBT4ypZu/7XjHY7VbI1yKBPII4Loaw5usrzwXEBZlAcbelkwfpB n+NDdKP8ZJAPhU5yCzhSi4fHmuYviX+QBObG1oBK8g== X-Google-Smtp-Source: AG47ELvbbnVZG/avZmCrSCt4xp79Z+G+jhZckVOYC8tcwTE+7BNYRxuryQey1ovNkyT7Z/RczvysHG6mUUqD7wvcZ4c= X-Received: by 2002:a25:6006:: with SMTP id u6-v6mr3767999ybb.460.1519497354117; Sat, 24 Feb 2018 10:35:54 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a25:dfcb:0:0:0:0:0 with HTTP; Sat, 24 Feb 2018 10:35:23 -0800 (PST) In-Reply-To: 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> <20180221201002.GC94212@kib.kiev.ua> <23181.54825.511195.393054@khavrinen.csail.mit.edu> <20180222212746.GB58772@stack.nl> From: Eitan Adler Date: Sat, 24 Feb 2018 10:35:23 -0800 Message-ID: Subject: Re: Marking select(2) as restrict To: Jilles Tjoelker , FreeBSD Hackers Cc: Garrett Wollman , 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: Sat, 24 Feb 2018 18:35:55 -0000 After this entire thread here is the summary. If I've misrepresented you here please let me know. Stefan Blachmann - concerned about possible breakages. kevlo - no comment julian@freebsd.org - no comment imp@ - concerned about lack of warnings; objected to original fix of devd Gary Jennejohn - pselect already has the modifiers. no comment. kib@ - no benefit; concerned fallout could be hard to observe Garrett Wollman - positive due to following the standard Tijil - glibc already uses it. limited fallout expected Eric van Gyzen - would prefer "make check" in the exp-run as well cem@ - concerned about warnings My thoughts: The main concern is that things /might/ break in undetectable was. However most other operating already have these marked as restrict, and no concrete brokenness for FreeBSD have been shown. I'd rather aim for correctness than avoiding speculative fallout. This is a tradeoff, but one I think is good here. Final action: I am planning on committing a modified version of the original patch after an exp-run. I will ask for port tests to be run if possible. This will be posted to phab for review for technical correctness. This will not be merged to stable/11. In the event of observable fallout it can be reverted. On 22 February 2018 at 23:26, Eitan Adler wrote: > On 22 February 2018 at 13:27, Jilles Tjoelker wrote: >> On Wed, Feb 21, 2018 at 03:27:21PM -0500, Garrett Wollman wrote: >>> < said: > ... > > FWIW > > glibc: already done - > https://github.com/bminor/glibc/blob/master/misc/sys/select.h#L101 > openbsd: already done > https://github.com/openbsd/src/blob/master/sys/sys/select.h#L128 > dragonflyBSD: alredy done: > https://github.com/dragonflybsd/dragonflybsd/blob/master/sys/sys/select.h#L50 > netbsd: already done: > https://github.com/NetBSD/src/blob/trunk/sys/sys/select.h#L69 > > The patch that started this thread was incomplete, as it didn't > include the timeval but I'll have an updated version in a phab soon. > > -- > Eitan Adler -- Eitan Adler From owner-freebsd-standards@freebsd.org Sat Feb 24 19:18:28 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 A836EF0654A; Sat, 24 Feb 2018 19:18:28 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-io0-f176.google.com (mail-io0-f176.google.com [209.85.223.176]) (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 29B2772577; Sat, 24 Feb 2018 19:18:27 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-io0-f176.google.com with SMTP id q24so5914597ioh.8; Sat, 24 Feb 2018 11:18:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=PXx8CmKVDudnZKn2lqRf3DuFpdxUr8+25dlD/o0mbuw=; b=cAlTPJHVnsCMJjMgVAfAV+Gh0AzQmPg2QKpN5uvW8OhVYwAdeB3J/iKkoYe81KDBH1 xZXn8+hxb+Q4lgRbLc5HjcJByzY+t6jvOpNbDZGflP8O16mjmNsCf9C9CIs+Pmg5AsAM 0nx6Qtqox1J/40DoeGDU3g99S5HPisFIv3s5ko7ekXMf+BHJBZE0d3ZqsdlVTdlB64UI 7eruJRyjJUS8HQ1+R05+oE/f9vvHe1WL9czYJ/wedVyWHrTLeqHAkFgzFp+vxX0PLtK1 qYpjwLpvxI2ZGkonUZhAy4gRRQt+FdzxsstUGwZb9PtH3iwJ3rDdDfOwMSiC+E0q+jN1 ol8g== X-Gm-Message-State: APf1xPDJAALpbKdLfTEjLYcfNq8O00Ljy36GAMyW9npvIiojo/1BiZdU MeShHfpvq+PRwLwC+4GzNHi8NLDa X-Google-Smtp-Source: AG47ELt81JlB3RyfsyZOQLqBZp5mF/vEmTxt0GTOCES5NDeXnzgjLfJifeqM2m5G2jPwrJeduQotCQ== X-Received: by 10.107.101.13 with SMTP id z13mr6021328iob.141.1519498551901; Sat, 24 Feb 2018 10:55:51 -0800 (PST) Received: from mail-io0-f172.google.com (mail-io0-f172.google.com. [209.85.223.172]) by smtp.gmail.com with ESMTPSA id k62sm2038036iod.28.2018.02.24.10.55.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 24 Feb 2018 10:55:51 -0800 (PST) Received: by mail-io0-f172.google.com with SMTP id p78so13143807iod.13; Sat, 24 Feb 2018 10:55:51 -0800 (PST) X-Received: by 10.107.222.10 with SMTP id v10mr6551362iog.267.1519498551638; Sat, 24 Feb 2018 10:55:51 -0800 (PST) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 10.2.30.149 with HTTP; Sat, 24 Feb 2018 10:55:51 -0800 (PST) In-Reply-To: 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> <20180221201002.GC94212@kib.kiev.ua> <23181.54825.511195.393054@khavrinen.csail.mit.edu> <20180222212746.GB58772@stack.nl> From: Conrad Meyer Date: Sat, 24 Feb 2018 10:55:51 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Marking select(2) as restrict To: Eitan Adler Cc: FreeBSD Hackers , 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: Sat, 24 Feb 2018 19:18:28 -0000 On Sat, Feb 24, 2018 at 10:35 AM, Eitan Adler wrote: > After this entire thread here is the summary. If I've misrepresented > you here please let me know. > ... > > kib@ - no benefit; concerned fallout could be hard to observe > cem@ - concerned about warnings Consider me a +1 to kib@. I did not voice those concerns explicitly in earlier email because kib did already and I didn't anticipate you would ignore him. Conrad From owner-freebsd-standards@freebsd.org Sat Feb 24 19:24:48 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 50439F07045 for ; Sat, 24 Feb 2018 19:24:48 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (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 990DD72B36 for ; Sat, 24 Feb 2018 19:24:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x230.google.com with SMTP id k135so1626012ite.2 for ; Sat, 24 Feb 2018 11:24:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=0PD9gOOjtdInxYQcjqWu8Y4Io/oLahzY9iFuR7EABek=; b=TvMJaiKgdUgb9lBQib8Bcmu95gwC1iXwMyiWA1qNr1KQUUbvmJD9/PXJ10aWqCRhDw uJPqxaKjjM19F0982Vju0P2bAJ0zJwwLFvtCnxnr8VQTYM5In7XMM6oRrxlrnqYbODsK TajFniP6UxajVZUqZK+WWzR2yX6tU3D250FiewAHFob7sukpQJglaH8Ph4yo/BnTkByb tbqP6FBkUPE4eDRSfvGjL91mRa3+oHIIs4yRRNHGchfRTiUSFNE5793MI/JTejMe4RZK 1JVQ88UXpt7uylWDpnCXSOLQf4IQ2cGdMPkuM0+AguhxZ9bH2ElkZiNdCxLivEGOFmL8 S7mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=0PD9gOOjtdInxYQcjqWu8Y4Io/oLahzY9iFuR7EABek=; b=uEw3Wsu+koVjXGljhCnFKOpqmQN4oZqhQjf0OaMBxTT3t4o1fdwBVaJRvlgxLmv3Wg EFFI2OliTnNVIt/PyyxtwDv8O/H7VCdHLTUcmgy25wtI28wa8YXiNUVex6FF3R6+LV0C cID9AyhrH7SkbUN3R5Hb6UbjGzswRfU+fC5kk6GE9y7RX44B6QqbaYacrb0XLsKTQQY7 GknH9B0ZHDrWzPGeyZwggLaG9xWWjlg3WR3HLkMhKrht/aghISCIwIgkSz1gfohT/IZa nT38LQerRj1W2t0sjXZTj/9auKsvwTIggWQ6/e58Cml9YxTJNAS7V9F1it4HoG73j3Gu e6vg== X-Gm-Message-State: APf1xPDebmIUB6GfrQ4Lh2nhpywDpz7VliHhjkC56mQYrXqOynZE1J9v V+ZD4k4iJbGkc624gbt8UoHbzT9I4v3jSKjs8/Ab8g== X-Google-Smtp-Source: AG47ELt647OapaU3F12OlM2cWT8YcMbQAH863VMQvrlzXTjVqzo/3/Y3efXc0jWP60IajKgumvRTcLv6R3T7jchPfuw= X-Received: by 10.36.6.70 with SMTP id 67mr7020461itv.57.1519500286471; Sat, 24 Feb 2018 11:24:46 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.201.67 with HTTP; Sat, 24 Feb 2018 11:24:45 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: 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> <20180221201002.GC94212@kib.kiev.ua> <23181.54825.511195.393054@khavrinen.csail.mit.edu> <20180222212746.GB58772@stack.nl> From: Warner Losh Date: Sat, 24 Feb 2018 12:24:45 -0700 X-Google-Sender-Auth: UjE_V0FEkGeWZwqGgXutPkNjIyI Message-ID: Subject: Re: Marking select(2) as restrict To: "Conrad E. Meyer" Cc: Eitan Adler , FreeBSD Hackers , FreeBSD Standards Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 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: Sat, 24 Feb 2018 19:24:48 -0000 On Sat, Feb 24, 2018 at 11:55 AM, Conrad Meyer wrote: > On Sat, Feb 24, 2018 at 10:35 AM, Eitan Adler > wrote: > > After this entire thread here is the summary. If I've misrepresented > > you here please let me know. > > ... > > > > kib@ - no benefit; concerned fallout could be hard to observe > > cem@ - concerned about warnings > > Consider me a +1 to kib@. I did not voice those concerns explicitly > in earlier email because kib did already and I didn't anticipate you > would ignore him. So there's no benefit to the change (we won't optimize better). It's hard to observe breakage. No answer about how we'd even know if something broke because a exp run sure as hell isn't going to tell us. All that militates against the change rather strongly. Your exp run will change no minds because it is useless. Warner From owner-freebsd-standards@freebsd.org Sat Feb 24 22:24:48 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 B8139F284DF; Sat, 24 Feb 2018 22:24:48 +0000 (UTC) (envelope-from joerg@bec.de) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 532C07ACD8; Sat, 24 Feb 2018 22:24:48 +0000 (UTC) (envelope-from joerg@bec.de) Received: from britannica.bec.de (p200300D2ABCCC4104639C4FFFE599710.dip0.t-ipconnect.de [IPv6:2003:d2:abcc:c410:4639:c4ff:fe59:9710]) (Authenticated sender: joerg@bec.de) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id ECF8DA80C6; Sat, 24 Feb 2018 23:24:44 +0100 (CET) Date: Sat, 24 Feb 2018 23:23:46 +0100 From: Joerg Sonnenberger To: Eitan Adler Cc: Jilles Tjoelker , FreeBSD Hackers , Garrett Wollman , FreeBSD Standards Subject: Re: Marking select(2) as restrict Message-ID: <20180224222346.GB16529@britannica.bec.de> Mail-Followup-To: Eitan Adler , Jilles Tjoelker , FreeBSD Hackers , Garrett Wollman , FreeBSD Standards References: <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> <20180221201002.GC94212@kib.kiev.ua> <23181.54825.511195.393054@khavrinen.csail.mit.edu> <20180222212746.GB58772@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.0 (2017-09-02) 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: Sat, 24 Feb 2018 22:24:48 -0000 On Sat, Feb 24, 2018 at 10:35:23AM -0800, Eitan Adler wrote: > The main concern is that things /might/ break in undetectable was. This argument puzzles me quite a bit. The code here is *already* broken and depends on unspecified behavior of the kernel, i.e. the order in which the fdsets are copied in/out. Joerg