Edit report at https://bugs.php.net/bug.php?id=47890&edit=1
ID: 47890 Updated by: yohg...@php.net Reported by: bernard dot fouche at kuantic dot com Summary: Function 'uniqid()' has a design flaw -Status: Open +Status: Verified Type: Feature/Change Request -Package: Feature/Change Request +Package: *General Issues Operating System: Any -PHP Version: 5.2.9 +PHP Version: master Block user comment: N Private report: N New Comment: It might be good to set more_entropy set to true for next PHP. W/o combined lcg, it has too weak uniqueness. Previous Comments: ------------------------------------------------------------------------ [2009-04-03 16:20:50] bernard dot fouche at kuantic dot com Description: ------------ IMHO 'uniqid()' does not provide any warranty about the returned id being really 'uniq': - uniqid() just calls 'gettimeofday()' (from php-5.2.9/ext/standard/uniqid.c): there is no warranty that the underlying operating system is able to really count microseconds. May be it counts by chunks of 10us, or 1ms, etc.. - With multi-core CPU and since AFAIK gettimeofday() is not a 'real' system call any more (on Linux) but reads from shared memory updated by the kernel, chances to have more than one process or thread being able to get the same value are much higher than with older hardware and OS implementations. - NTP may update the system time and whack the microsecond counter at any time. I think that uniqid() should rely on other information, like the process ID, thread ID, and an internal counter... Sure the programmer can use the 'prefix', but then what is the purpose of this function if the programmer has to take care about these details? Reproduce code: --------------- --- >From manual page: function.uniqid --- ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=47890&edit=1
