I realize I have been vague. I should have been more clear about that the input values have typically been through C functions limited to native integers to begin with. The canonical situation is the one I already mentioned, namely the size of something in memory, where Pike.NATIVE_MAX works well as an upper bound since it scales with the addressable memory (unless possibly if someone compiles his pike with very odd configure options, but I couldn't care less about that).
When I said "no fixed limits" I meant in that case that I won't make an effort to limit the input so that no overallocation of memory can occur. I just conclude that memory will run out long before Pike.NATIVE_MAX size is reached, and hence that choice of upper bound value is safe.
Doing a quick search through a large chunk of my code shows that the memory size limited domain pretty much covers my use of Pike.NATIVE_MAX. There is however one more case when I've chosen to use it: As a value larger than any maximum cache time value (in seconds) for things in a RAM cache.
That is a case where I think it serves well as an idiom: Anything larger would incur unnecessary runtime overhead, and anything smaller would raise a suspicion that there could be some relevance to the value as an actual limit in itself.
It's an example of a domain that "of course" is considerably smaller. Sure, I am strictly speaking making an error in that case: If someone would manage to the same process running for about one life time then cache entries could time out prematurely on a 32-bit architecture. Even so I think the clarity of the idiom outweighs that theoretical problem.