For Kurtis: I know the map will choose random hash seed to init itself, and the iterator will also choose random order to iterate map. And I know it is a bad idea to add or delete a key when iterating a map, but I want to know what causes the inpredictable result, not the key's iterating order, but the key's count that was printed.
在2020年11月11日星期三 UTC+8 上午11:56:51<Kilos> 写道： > For Dan: > I have an idea that the cause is in the runtime function mapiternext. > The runtime calls mapiternext function to choose next bucket to iterate by > index, > if we put a key-value into a bucket which already be iterated, then the > for-range will not iterate it again, > so the new key-value will not be printed. > But I don't know this idea is true or false. > 在2020年11月11日星期三 UTC+8 上午11:16:41<kortschak> 写道： > >> On Tue, 2020-11-10 at 19:08 -0800, 'Kilos' via golang-nuts wrote: >> > Thanks for reply, but I want to know the underlying reason about it, >> > I think the reason is in how the runtime functions works. >> >> The direct cause is that the hash function used for the map >> implementation is seeded from the system clock. >> >> The reason for doing this was largely to avoid time complexity attacks >> against servers that use maps for passing arguments in URIs. >> >> >> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/2bce0e77-459e-4cdb-84a8-eca2c10748cfn%40googlegroups.com.
