From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE,RDNS_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 Received: (qmail 19676 invoked from network); 15 Mar 2020 19:14:39 -0000 Received-SPF: pass (primenet.com.au: domain of zsh.org designates 203.24.36.2 as permitted sender) receiver=inbox.vuxu.org; client-ip=203.24.36.2 envelope-from= Received: from unknown (HELO primenet.com.au) (203.24.36.2) by inbox.vuxu.org with ESMTP; 15 Mar 2020 19:14:39 -0000 Received: (qmail 8354 invoked by alias); 15 Mar 2020 19:14:34 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: List-Unsubscribe: X-Seq: 45565 Received: (qmail 28979 invoked by uid 1010); 15 Mar 2020 19:14:34 -0000 X-Qmail-Scanner-Diagnostics: from out5-smtp.messagingengine.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.2/25751. spamassassin: 3.4.2. Clear:RC:0(66.111.4.29):SA:0(-2.6/5.0):. Processed in 4.665483 secs); 15 Mar 2020 19:14:34 -0000 X-Envelope-From: d.s@daniel.shahaf.name X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at daniel.shahaf.name does not designate permitted sender hosts) X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudefuddgvdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfffgrnhhivghlucfuhhgrhhgrfhdfuceougdrshesuggr nhhivghlrdhshhgrhhgrfhdrnhgrmhgvqeenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpegurdhssegurghnihgvlhdrshhhrghhrghfrdhnrghm vg X-ME-Proxy: X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-991-g5a577d3-fmstable-20200305v3 Mime-Version: 1.0 Message-Id: <0c163473-1349-4377-ac79-917ad8db7aee@www.fastmail.com> In-Reply-To: <20200315183616.psa3fhuzsvcmzcga@phare.normalesup.org> References: <20200111154143.fjtwgfnztqfmkyda@phare.normalesup.org> <20200308183907.mxnhqrr2uflwooax@phare.normalesup.org> <20200314210454.hp562smyqv3ew255@phare.normalesup.org> <20200315005036.45bc846b@tarpaulin.shahaf.local2> <20200315160324.dstgtmajzwxpaccn@phare.normalesup.org> <20200315165410.GA30241@tarpaulin.shahaf.local2> <20200315183616.psa3fhuzsvcmzcga@phare.normalesup.org> Date: Sun, 15 Mar 2020 19:13:31 +0000 From: "Daniel Shahaf" To: "Cedric Ware" Cc: dana , zsh-workers@zsh.org Subject: Re: [PATCH] Enable sub-second timeout in zsystem flock Content-Type: text/plain Cedric Ware wrote on Sun, 15 Mar 2020 18:36 +00:00: > > Daniel Shahaf (Sunday 2020-03-15): > > Cedric Ware wrote on Sun, Mar 15, 2020 at 17:03:24 +0100: > > > I think that was about my earlier attempt to include the actual limit > > > in the error message, not the input. I reverted to a generic message, > > > because I don't know how to make the test script check for an error > > > message that depends on the system/compiler options. > > > > How would the message depend on the system/compiler options? > > Not with your suggestion, which I implemented. My original idea was > for an error message like "invalid timeout value, maximum is N", where > N would be ZLONG_MAX / 2 / 1000000. But to display the latter, I'd > have needed a way to output a zlong, which has just now been proposed. > Would it be useful? I think the important part is to display the invalid input. I don't immediately see a situation in which I'd run into the input validation error message and be glad that it spelled out the value of (2**63 / 2e6) for me. > > > Still, would you like it better if I limited the interval to > > > min(LONG_MAX, ZLONG_MAX / 2) instead of LONG_MAX? > > > > Well, it sounds like that won't make any difference to bin_system_flock()'s > > behaviour in practice (at least until someone has servers with uptimes > > on the order of tens of kiloyears), so I don't have a strong preference. > > I suppose I'd recommend whichever of these is more likely to remain > > correct even if the code is copied elsewhere and adapted. > > Changing the limit should be easy. I see there is a macro minimum(). > Can I assume that a long can always be promoted to a zlong? Given that we assume zlong is >= 64 bits long, the only way this can be false is if long is int128_t (or larger) and zlong is int64_t, isn't it? I don't know of any platform where that'd be true. Cheers, Daniel