Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:111458 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 33736 invoked from network); 11 Aug 2020 13:14:07 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 11 Aug 2020 13:14:07 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 0AE5F1804D9 for ; Tue, 11 Aug 2020 05:13:29 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-vk1-f181.google.com (mail-vk1-f181.google.com [209.85.221.181]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 11 Aug 2020 05:13:28 -0700 (PDT) Received: by mail-vk1-f181.google.com with SMTP id q200so2575018vke.6 for ; Tue, 11 Aug 2020 05:13:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=basereality-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=TlncXvAle7JmkbLed5mpPl/tvKrBWBaKxz0SsjA/Zms=; b=uv2XoaFmZzOqw1H7g7JaPDkkRkdXL1TAbGkBe3cLE5yVDQP0CVfuBwGx5O70tYX3mB DEP5XXTDlI7qS8Ou5oGS7PgOdCKPO9Zz99o57AKar88uHbJVq2yqDN/FYpLxN9/UU8+3 BxAHs4hjZTfG+k0h3+BDSObZBmhqJHXczyEYTnu7ypDLa4C9Y23MKFSff+j143RMRJ0Y Nb7m3Sz8d20yquw2wXhB5MUs6K0tseVO+VHUj5kcxNtMzPwivjZzy0dX88HBdFpSdUJ1 RSHGAuLoUqE+ANBCK5ZxhdzAN1k7klidsWf6jxdHLkFCvZ4IfnaOOlTIPrFC325svEwu wtHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=TlncXvAle7JmkbLed5mpPl/tvKrBWBaKxz0SsjA/Zms=; b=ldr1FSZnongtw9L3rGjsRanIblBp6Zri9ZL1QPbgJFMscytn9XANB5tE5wt88zQVWh k70smS6s3IvTp8gwC6EiXz2GAZfOj1Kt2baBwXWBusPsym/Yqf0nDBWa3OF58GE1s4tT lF5EE/ZPoL6CgT4XmJOvsr2K+WgykjWJT+FQRpcfSACQrBpXdhiCs+BXGyaKgJqzcx6H Rtayfkn4uqp8fTZOF97d7RLzRmUNISYJsrSOTRlk4sSuAeWcLGFGb9XRk9bPYmT160kO 6xvBvIMuAqa4TlHOAWwhjpQxAOsbfwfxPSNeeMtrdcrzI21j/OYRoTKkdx9bRmwGh+v0 khJw== X-Gm-Message-State: AOAM531Ncj7biT+NNdSACKUKjzbakB/g2JgBnsObghx4ncRfHZQewVdC 59RdcmrUult/QWplxiBKinvhlurAPZY/pyaquiUsdA== X-Google-Smtp-Source: ABdhPJzV7X9qwVNb8p1BD6jBuqUC9ryFQvhVRMOdK0cCDyu87iL6h5vdoXnv9pb9maUHUYh13ZY5SNysa8K2ISHF6yw= X-Received: by 2002:a1f:2ac1:: with SMTP id q184mr24248882vkq.18.1597148004707; Tue, 11 Aug 2020 05:13:24 -0700 (PDT) MIME-Version: 1.0 References: <6cfb77d4d511b5c591e7d7b5cc80199955123b2cd4276a5bca2327e4b02942db@mahalux.com> In-Reply-To: Date: Tue, 11 Aug 2020 13:13:13 +0100 Message-ID: To: "G. P. B." Cc: =?UTF-8?B?TWljaGFlbCBWb8WZw63FoWVrIC0gxIxWVVQgRkVM?= , PHP internals , =?UTF-8?Q?Bj=C3=B6rn_Larsson?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] Allow sleep() to accept non-integer values From: Danack@basereality.com (Dan Ackroyd) Bj=C3=B6rn Larsson wrote: > Given this unexpected behaviour, one could almost see it as a bug. This isn't a suddenly noticed new bug. That code has worked like that since the sleep function was committed twenty-two years ago or for five years since the release of PHP 7 and the weak/strict RFC continued the "if you don't want float -> int conversions, use strict mode" choice. There are quite a few functions in PHP that take int parameters, that have this behaviour. These could all be 'fixed' by people using strict mode, and you could make a good argument for making strict mode the default, but it's probably a bit late in the 8.0 release cycle for that, and it _might_ be a little contentious. I agree that the PHP standard library is not as good as it could be, but tweaking it piece-by-piece is not a good way of fixing it. Doing it like that would lead to subtle BC breaks that are not obvious. G.P.B. wrote: > I'd rather see the failure condition changed to reject 0 or add a > E_NOTICE/E_WARNING if 0 is passed as this has questionable semantics. sleep(0) is a useful thing to do in some circumstances. It has the same effect as Thread.yield() in Java. Or in English, it allows a process to say "Hello OS scheduler, I don't want to sleep right now, but if there are any other threads that are waiting for their turn, now is a great time to suspend my execution, as I'm not in the middle of anything, otherwise I'll keep processing." Again, yes we need a better way of evolving the core libraries. But tweaking it on a function by function basis is not a good way of doing that. cheers Dan Ack