sherwood_v8_block::empty_block() oddities about flat_hash_map HOT 1 OPEN

I'm fairly certain the C++ standard guarantees that the existing code is correct. Dynamic linkage alone shouldn't affect this unless your compiler or linker has bugs.
I can only imagine three ways this could break:

• If you're doing something weird with threading that makes all variables with static storage duration thread-local (I don't know if that's even possible), then if empty_block is called from two different threads, it may result in two different pointers.
• If sherwood_v8_block is defined differently in two different translation units (e.g. defining certain macros before including the header, or using different versions of the header), it could result in two separate versions of it, breaking ODR.
• If you're interpreting an instance of the class in two different ways using casts, you may be calling two separate versions of this function.

If changing the definition as you said actually fixes this, then I think that only the first case could be true.

EDIT: See #26. Depending on how the standard is interpreted, shared objects may not be considered translation units as per the standard's usual definition. Linux has the safer and more conforming behavior, Windows may not. This StackOverflow question explains this in more detail.

from flat_hash_map.