From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from primenet.com.au (ns1.primenet.com.au [203.24.36.2]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id a32b291b for ; Sat, 11 Jan 2020 15:42:34 +0000 (UTC) Received: (qmail 19592 invoked by alias); 11 Jan 2020 15:42:28 -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: 45281 Received: (qmail 13721 invoked by uid 1010); 11 Jan 2020 15:42:27 -0000 X-Qmail-Scanner-Diagnostics: from nef2.ens.fr by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.1/25684. spamassassin: 3.4.2. Clear:RC:0(129.199.96.40):SA:0(-4.2/5.0):. Processed in 3.958036 secs); 11 Jan 2020 15:42:27 -0000 X-Envelope-From: ware@phare.normalesup.org X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at ens.fr designates 129.199.96.40 as permitted sender) X-ENS-nef-client: 129.199.129.80 Date: Sat, 11 Jan 2020 16:41:43 +0100 From: Cedric Ware To: dana Cc: "zsh-workers@zsh.org" Subject: Re: [PATCH] Enable sub-second timeout in zsystem flock Message-ID: <20200111154143.fjtwgfnztqfmkyda@phare.normalesup.org> References: <20190729203521.upp5ku3bsr3hsnxq@phare.normalesup.org> <20200104184734.ienw42rwq2xu6aap@phare.normalesup.org> <43775C64-0254-45AB-81AB-B04AE80C4416@dana.is> <20200106173030.eb2pg4rhhgysh35r@phare.normalesup.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (nef.ens.fr [129.199.96.32]); Sat, 11 Jan 2020 16:41:44 +0100 (CET) dana (Monday 2020-01-06): > Like i said, it doesn't seem to do much error-checking anywhere else, so i > guess it's consistent... but if it were me i'd probably make any out-of-range > value return an error, yeah. Easy enough, except that producing a useful error message, with the actual maximum value, is trickier than I'd expected. zerrmsg() (and thus zwarnnam()) only supports displaying a long (%L) if DEBUG is enabled (see "#ifdef DEBUG" lines 290 and 328 of Src/utils.c), and no floating-point types. Is this deliberate? I can see why floats would be harder to support, but long seems harmless. If %L can be enabled in zerrmsg() then, getting back to zsystem/flock, if there's an overflow on the value of the retry interval, it's easy to display an error message saying that the value is limited to LONG_MAX / 1000000L seconds (slightly underestimated for display purposes). As for an overflow on the (64-bit) timeout value, it's harder to display the maximum value, but then users are less likely to stumble into an overflow so I'd leave it silent and perhaps document it. If not, there's always the possibility of displaying a generic "value too large" message. dana (Monday 2020-01-06): > On 6 Jan 2020, at 11:30, Cedric Ware wrote: > > Thanks for the pointer. Yes, that could be done, though I don't have > > the time right now. What I actually had in mind was a test suite I > > could run to check that I didn't break anything elsewhere. Which is > > "make test", I should have thought of it. The current tests are still > > successful with the patch. > > I'm slightly busy again too but i could try to write a script for it later. As I've never done this before, I'd feel more confident adding tests to an existing script than trying to learn and write one from scratch. Thanks, best regards, Cedric Ware.