[0xcde4c3db]

Also, the specific phrase "undefined behavior" is typically invoked in a context related to the C programming language. In the C standard and some standards related to it, undefined behavior is just one point on a spectrum of (un)definedness:

- implementation-defined: Not defined by the standard, but implementations must choose a consistent behavior and document it (e.g. what's shifted in when right-shifting signed integer types)

- unspecified: Not defined by the standard; implementations must choose some way of addressing the situation, but need not document it (e.g. the order in which function arguments are evaluated)

- undefined: Entirely outside the scope of the standard; implementations may assume that such situations never occur, and need not have any sensible or consistent behavior (e.g. dereferencing NULL)

In that taxonomy, I think this is much closer to "unspecified" than "undefined". The latter is usually used in scarier contexts like random memory corruption or crashes, not consistent behaviors that rely on deliberate implementation choices as we see here.