zsh-workers
 help / color / mirror / code / Atom feed
From: Cedric Ware <cedric.ware__bml@normalesup.org>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: Daniel Shahaf <d.s@daniel.shahaf.name>,
	Sebastian Gniazdowski <sgniazdowski@gmail.com>,
	Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: [BUG] zsystem:34: flock: invalid timeout value: '0'
Date: Sat, 27 Jun 2020 09:13:50 +0200	[thread overview]
Message-ID: <20200627071350.zqkdhzbk3mfej2tz@phare.normalesup.org> (raw)
In-Reply-To: <CAH+w=7YuMOOSbsgop53ZpCGQZ=COGBSS_nMAyS7m6aQ_YmpukA@mail.gmail.com>


	Hello,

Bart Schaefer (Friday 2020-06-26):
> It's pretty obvious that the patch caused the change:
> 
> +               if (timeout < 1e-6 || timeout > 1073741823.) {
> +                   zwarnnam(nam, "flock: invalid timeout value: '%s'",
> +                            optarg);

Yes, sorry, didn't catch the 0 case.

> Similarly:
> 
> +               if (timeout_param.u.d < 1
> +                   || timeout_param.u.d > 0.999 * LONG_MAX) {
> +                   zwarnnam(nam, "flock: invalid interval value: '%s'",
> +                            optarg);

I don't think so.  This one is for the -i parameter, which is new,
it's not a behavior change.  And IMO it doesn't make sense to allow
a zero interval.

> I don't know enough about dealing with the float-valued time specs to be
> sure what to do about it, i.e., why a limit above zero was considered
> necessary or whether zero needs to be a special case.

I didn't want to allow specifying a timeout below 1 microsecond,
because that's the granularity of zsleep().  One could still allow it
but silently treat it as 0.  In any case, the 0 value itself should
indeed have been allowed.  Here's a quick patch below, I've tested it,
but I don't have time right now to do much more.

					Best regards,
					Cedric Ware.


diff --git a/Src/Modules/system.c b/Src/Modules/system.c
index 972aa0767..638fe029e 100644
--- a/Src/Modules/system.c
+++ b/Src/Modules/system.c
@@ -591,13 +591,16 @@ bin_zsystem_flock(char *nam, char **args, UNUSED(Options ops), UNUSED(int func))
 		    timeout_param.u.d : (double)timeout_param.u.l;
 
 		/*
+		 * timeout can be 0 (no wait) but not so small as to be
+		 * less than a microsecond.
 		 * timeout must not overflow time_t, but little is known
 		 * about this type's limits.  Conservatively limit to 2^30-1
 		 * (34 years).  Then it can only overflow if time_t is only
 		 * a 32-bit int and CLOCK_MONOTONIC is not supported, in which
 		 * case there is a Y2038 problem anyway.
 		 */
-		if (timeout < 1e-6 || timeout > 1073741823.) {
+		if (timeout != 0. &&
+		    (timeout < 1e-6 || timeout > 1073741823.)) {
 		    zwarnnam(nam, "flock: invalid timeout value: '%s'",
 			     optarg);
 		    return 1;
diff --git a/Test/V14system.ztst b/Test/V14system.ztst
index b8af96cda..06512fe05 100644
--- a/Test/V14system.ztst
+++ b/Test/V14system.ztst
@@ -13,7 +13,9 @@
 %test
 
   (
-    zsystem flock -t 0.1 -i 0.000001 $tst_dir/file
+    zsystem flock -t 0 -i 0.000001 $tst_dir/file   &&
+    zsystem flock -t 0.1 -i 0.000001 $tst_dir/file &&
+    zsystem flock -t 1 -i 0.000001 $tst_dir/file
   )
 0:zsystem flock valid time arguments
 

  reply	other threads:[~2020-06-27  7:14 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-25 17:49 Sebastian Gniazdowski
2020-06-26 14:16 ` Daniel Shahaf
2020-06-26 19:42   ` Sebastian Gniazdowski
2020-06-27  1:47     ` Daniel Shahaf
2020-06-27  2:04       ` Bart Schaefer
2020-06-27  7:13         ` Cedric Ware [this message]
2020-06-27  7:27           ` Roman Perepelitsa
2020-06-27 17:01             ` Bart Schaefer
2020-06-27 17:12               ` Roman Perepelitsa
2020-06-27 17:58                 ` Bart Schaefer
2020-06-27 18:09                   ` Roman Perepelitsa
2020-06-27 20:38             ` Cedric Ware
2020-06-28  9:27               ` Roman Perepelitsa
2020-07-10 15:28                 ` Sebastian Gniazdowski
2020-07-11  5:18                   ` dana
2020-06-27 17:25           ` Sebastian Gniazdowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200627071350.zqkdhzbk3mfej2tz@phare.normalesup.org \
    --to=cedric.ware__bml@normalesup.org \
    --cc=d.s@daniel.shahaf.name \
    --cc=schaefer@brasslantern.com \
    --cc=sgniazdowski@gmail.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).