Temporary names produced by the commands tempvar and tempname are composed of two leading underscores followed by a six digit number in base 36. Producing temp names will result in __000000, __000001, __000002, ..., __000009, __00000A, __00000B, ..., __00000Z, __000010, __000011, etc.
Like me, you might naively assume this means that there are at least 36^6 = 2,176,782,336 different possible temp names. This is far more than could ever be needed or concurrently used, but since the documentation says that temp names "are guaranteed to be unique" (from one another), I was curious to know what happens when this limit is reached.
Turns out, after reaching __ZHYLDQ, temporary name generation loops back to __000000. This is the 2,146,483,647th generated name. Notably, this number is not 2^31 - 1, the maximum value for a signed 32-bit integer, which comes up as a limit for Stata in several other locations (highest value for set seed, highest possible return code, and longest string byte length in Mata, among others). It's exactly one million less, or 2^31 - 1,000,001.
If this was a purposeful choice by StataCorp, I'd be fascinated to know why. If it's the result of a typo somewhere, I'd hesitate to call this a glitch, since it does not negatively impact the use of the program at all. It would never come up unless you're purposefully testing for it, or you're doing something extremely incorrectly. Either way, I thought it was interesting and wanted to document it somewhere.
Like me, you might naively assume this means that there are at least 36^6 = 2,176,782,336 different possible temp names. This is far more than could ever be needed or concurrently used, but since the documentation says that temp names "are guaranteed to be unique" (from one another), I was curious to know what happens when this limit is reached.
Turns out, after reaching __ZHYLDQ, temporary name generation loops back to __000000. This is the 2,146,483,647th generated name. Notably, this number is not 2^31 - 1, the maximum value for a signed 32-bit integer, which comes up as a limit for Stata in several other locations (highest value for set seed, highest possible return code, and longest string byte length in Mata, among others). It's exactly one million less, or 2^31 - 1,000,001.
If this was a purposeful choice by StataCorp, I'd be fascinated to know why. If it's the result of a typo somewhere, I'd hesitate to call this a glitch, since it does not negatively impact the use of the program at all. It would never come up unless you're purposefully testing for it, or you're doing something extremely incorrectly. Either way, I thought it was interesting and wanted to document it somewhere.
