Bug #65626 [Fbk->Opn]: uniqid(null, false) should guarantee unique identifier

Edit report at https://bugs.php.net/bug.php?id=65626&edit=1 ID: 65626 User updated by: cmbecker69 at gmx dot de Reported by: cmbecker69 at gmx dot de Summary: uniqid(null, false) should guarantee unique identifier -Status: Feedback +Status: Open Type: Bug Package: Unknown/Other Function Operating System: WIN32 PHP Version: 5.4.19 Block user comment: N Private report: N New Comment: I have tested the build with Yasuo's patch on Windows 7 Home Premium SP 1, and it works fine, i.e. I was not able to produce identical uniqid()s. I couldn't test it on an old XP Home SP 3 machine, though, as the build seems to be a 64bit build. > A timeout is still something delaying the script execution, > even for 1us, that's what a PHP developer can decide for > the concrete script. Yes, of course. However, a portable script would have to add the call to usleep(), even if it's unnecessary for *nix systems and actually causes a delay of 2 us there. And actually, I don't see a real issue with using usleep() in uniqid(), as usleep() is used by PHP's usleep()[1], so there would be issues as well. Shifting the burden of calling usleep() to userland won't solve these issues. Regarding Cygwin: I did some builds of PHP 5.4.? and PHP 5.5.? more than half a year ago. However, not everything was usable (e.g. Opcache had to be disabled; otherwise ./configure failed). And the test suite produced a bunch of failures; I tried to submit the resulting report (nearly 1 MB) to the QA list, but somehow it never made it through. FWIW: I didn't manage to build PHP on Cygwin64. [1] <http://lxr.php.net/xref/PHP_5_5/ext/standard/basic_functions.c#4461> Previous Comments: ------------------------------------------------------------------------ [2014-02-10 10:56:58] ab@php.net @cmbecker69, with reopening it was addressed to Yasuo. Uniqueness of that identifier is applicable in the microseconds range only. That scope is also documented, so the behavior is legit. That's the main idea in the helly's post, i think. And his post relates back to 2006 while the relevant code to 2002. For the reasons not to do it on native windows, see below. @yasuo, I've tested your patch on the native windows builds on different VM, it delivers so far without having to use usleep() in the user space. @cmbecker69, could you please test this build http://windows.php.net/downloads/snaps/ostc/65626/ with Yasuo's patch? Still I wouldn't push for this change, testing in VM is something else as the real hardware. Unfortunately I've VMs only right now. Besides that, working on the microtime() bugs has shown that many different constellations of hardware/platform cause various disservices. So fixing it for several constellations contains a high possibility to break it for others. Also in the light of how win8 works now having much better time accuracy, it's probably not future oriented. A timeout is still something delaying the script execution, even for 1us, that's what a PHP developer can decide for the concrete script. So i really think there are more factors against changing this part, except cygwin maybe. The cygwin part is still to be tested by someone who has the build env. Thanks. ------------------------------------------------------------------------ [2014-02-09 12:16:40] cmbecker69 at gmx dot de helly wrote: | To ensure this we use usleep() internally to either force a | thread (windows) or process (*nix) switch. From what I can tell, usleep() is not called on Windows.[1] ab wrote: | For instance, on win8 a snippet "while(uniqid(null, false) | != uniqid(null, false));" loops forever with 5.4 even if | it doesn't have to. However, the documentation[2] states: | Gets a prefixed unique identifier based on the current time | in microseconds. IMHO, a unique identifier should be unique. I have not changed the status, because I had not re-opened the ticket nor had I reported it as bug, but rather as a feature request. [1] <http://lxr.php.net/xref/PHP_TRUNK/ext/standard/uniqid.c#61> [2] <http://php.net/manual/en/function.uniqid.php> ------------------------------------------------------------------------ [2014-02-09 12:16:39] cmbecker69 at gmx dot de helly wrote: | To ensure this we use usleep() internally to either force a | thread (windows) or process (*nix) switch. From what I can tell, usleep() is not called on Windows.[1] ab wrote: | For instance, on win8 a snippet "while(uniqid(null, false) | != uniqid(null, false));" loops forever with 5.4 even if | it doesn't have to. However, the documentation[2] states: | Gets a prefixed unique identifier based on the current time | in microseconds. IMHO, a unique identifier should be unique. I have not changed the status, because I had not re-opened the ticket nor had I reported it as bug, but rather as a feature request. [1] <http://lxr.php.net/xref/PHP_TRUNK/ext/standard/uniqid.c#61> [2] <http://php.net/manual/en/function.uniqid.php> ------------------------------------------------------------------------ [2014-02-08 22:03:49] ab@php.net Hi, I'm not sure why you reopen this ticket :) If you read the helly's comment in bug #37106, it's pretty matching. uniqid() isn't in any way expected to be predictable on different platforms. Btw. never tried to compile it under cygwin. Also see the history, that part was introduced in 2002. Were cygwin builds ever been seriously supported? So where you see a bug here? Nevertheless, the uniqid function is documented as not being secure. usleep() can be used from the userspace and the value is highly variable depending on the platform and hardware. Thanks. ------------------------------------------------------------------------ [2014-02-08 21:09:12] yohgaki@php.net #if HAVE_USLEEP && !defined(PHP_WIN32) !defined(PHP_WIN32) seems legacy check to me as PHP's usleep() only checks HAVE_USLEEP. #if defined(__CYGWIN__) Why Cygwin requires more entropy? I guess the #if check is for assuring uniqueness of uniqid(). Is this needed still? I think we need Windows experts. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=65626 -- Edit this bug report at https://bugs.php.net/bug.php?id=65626&edit=1