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

Edit report at https://bugs.php.net/bug.php?id=65626&edit=1 ID: 65626 Updated by: cmb@php.net Reported by: cmbecker69 at gmx dot de Summary: uniqid(null, false) should guarantee unique identifier -Status: Open +Status: Closed -Type: Bug +Type: Feature/Change Request Package: Unknown/Other Function Operating System: WIN32 PHP Version: 5.4.19 -Assigned To: +Assigned To: cmb Block user comment: N Private report: N New Comment: Since the documentation clearly states that uniqid() is not guaranteed to return unique values, this is not a bug, but rather a feature request. Since there is already an RFC addressing this issue[1], I'm closing this ticket. @601115211: Please do not file bug reports to existing but unrelated tickets. File a new bug report instead. However, in this case it is not necessary, because the behavior of ltrim() is expected, because the second parameter is supposed to be a character *mask*. Try ltrim($str, 'HTP_') to understand the behavior. [1] <https://wiki.php.net/rfc/uniqid> Previous Comments: ------------------------------------------------------------------------ [2017-11-21 01:06:22] 601115211 at qq dot com <?php $str = 'HTTP_TOKEN'; echo "PHP_VERSION:",PHP_VERSION,PHP_EOL; echo ltrim($str, 'HTTP_'); Expected result: ---------------- TOKEN Actual result: -------------- OKEN ------------------------------------------------------------------------ [2014-02-10 17:48:35] cmbecker69 at gmx dot de Thanks, Anatol, for the explanation and the link to the other ticket. Finally, I understand the problem, and that it can't be cleanly fixed for older Windows systems. Regarding the Cygwin issue see bug #27182. It seems the patch provided by sagawa works fine. However, I agree that Cygwin support is of minor importance nowadays. ------------------------------------------------------------------------ [2014-02-10 16:20:23] ab@php.net @cmbecker69, thanks for testing. It won't work on XP as it's a master+patch build with vc11. The issue isn't directly with usleep() but with the subsequent gettimeofday(). What I meant earlier about microtime, that even after hardcoded usleep(1) gettimeofday still could deliver some inaccurate result, which would mean same old behaviour and the waste of that 1us. And that is something we can't do much about, because it depends on hardware and platform. Well, except of using the newer APIs. So that can't be the same as on linux by best will, please read bug #64633 for more info. A portable script will have to check a lot of things anyway. I'm really not sure whether someone works with cygwin that way. Native builds are of much better quality, and if one needs the unix style - so there's a VM :) Thanks. ------------------------------------------------------------------------ [2014-02-10 14:29:38] cmbecker69 at gmx dot de 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> ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ 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