[I attributed "silly" to your rather nonconstructive argument, not to you.]
And my point was that I just turned your own argument around, substituting one arbitrary constant for another (incidentally an invariant one, which is better)...
Seems like you choose to ignore the key issue here, namely C functions which are limited to native integers.
Not really, but I was a bit tired yesterday, so I guess my point didn't get across very well.
Let me make another, more structured attempt. :-)
The assumption made here is that you have
1) Some input set I, the elements of which are truly unbounded.
2) An algorithm A, operating on I, which requires an element î which is larger than any element in I.
3) A function (implemented in C or otherwise) f which has a limited input range [..L], which is fed the elements of an output set O produced by A.
If A produces outputs used for multiple functions with bounded inputs, simply generalize the above to O1, O2, f1, f2, L1, L2 etc.
Your argument was that since elements in I are unbounded, you can get elements in O which are also unbounded, which may cause f to fail, and so you are doomed anyway.
Well, there are two ways you can cope with unsuitable input. You can either detect it early, and handle it gracefully, or you can ignore it and just let the code crash and burn. The appropriate choice depends on the situation of course (how likely are the unstuitable inputs, is the code intended for production use, etc). So I'll cover both alternatives separately.
I'll take the "crash and burn" approach first, since that's the one you appeared to be proposing.
If your algorithm A is capable of working with large numbers, you'll get an output set O which is always correct, but which may contain elements o' not supported by f. The result of such an element will be that f throws an error, saying that the input parameter is out of bounds. This makes it easy to see exactly what went wrong, and since the o':s are from the correctly computed O, their values should come as no surprise.
If the algorithm on the other hand uses an î which is actually less than one of the elements in I, an assumption upon the algorithm itself is based has been violated, and the contents of O might be anything. It could still contain values larger than L, in which case you'd still get the backtrace, but now potentially with a mystery value which wasn't supposed to be in O, or it could just be wrong, while still containing only legal values, in which case your program would keep running and you might not discover the error until much later, when it will require much head scratching to discover.
So the use of an incorrect î here will only make errors more difficult to find. A modified algorithm which does not require an î larger than all values in I is clearly preferable, and also easy to construct from A with simple transformations (although putting some more thought to it can produce something more efficient).
For the second option, you need to do a little more work. Firstly, you need to find out what L really is. It may be both larger and smaller than Pike.NATIVE_MAX. For example, the argument to the seek() function is bounded, but on some systems the bound is much larger than Pike.NATIVE_MAX. On the other hand, the first argument to the bind() function has a bound which is always smaller than Pike.NATIVE_MAX. Having constants for the actual bounds of built-in functions might be nice, actually. Secondly, you need to consider the transfer functor T, which is used to construct the elements in O from the elments in I. It might be identity, but it might also be something else. The crux is that the input values need to be checked against the value of L under T^-1, not L itself. Let's call this value L'. Now that you know L', you can test the inputs against L', and do some appropriate error recovery (print a message or whatever, possibly proceeding with the offending element removed from I). By putting this check before A, you can safely use L' as î, because the now the input of A isn't unbounded anymore, but rather has a domain-specific bound. Again, note that L' may very well be different from Pike.NATIVE_MAX, especially since you need to consider the Ln:s and Tn:s of all fn:s.
For a quick hack, you may of course chose to ignore the above and use an incorrect î (Pike.NATIVE_MAX, 100000, time() or whatever) fully knowing that it may cause weirdness, but plugging it as "an idiom" is in rather bad taste, IMO.