[thelist] ASP: DIM var AS ??
Paul Cowan
evolt at funkwit.com
Wed Jul 2 19:37:15 CDT 2003
Chris W Parker wrote:
> SORRY! ;P
That's OK. Just gave me a fright. :)
> But still CLng() has a limit doesn't it? Granted it's much higher
> than CInt(), but still you're not ultimately protecting from that
> variable having an overflow since CLng() has a limit as well correct?
Yes, it certainly does. As a 32-bit signed number, a long has an upper
limit of (2^31 - 1), or 2,147,483,648.
So you can never be sure that you're safe, but you can at least
reduce risks a little. It may not be worth it for you, but we deal
with some seriously big database tables and CInt() was just causing us
no end of drama, so we canned it totally. If you're only dealing with
small numbers -- and you're SURE -- go nuts.
> Ultimately how do you protect from an overflow? Can you test the size
> of the variable and truncate it if it's too big?
Short answer? Not really, as far as I know. Not without converting it
to a long!
Though you could hack it... say you're taking in a string, you could do
something like:
blnSafeToConvert = false
if IsNumeric(strValue) then
if len(strValue) <= 9 then
blnSafeToConvert = true
elseif len(strValue = 10) then
select case left(strValue, 1)
case "1"
blnSafeToConvert = true
case "2"
if clng(right(strValue, 9)) < 147483648 then
blnSafeToConvert = true
end if
end select
end if
end if
if (blnSafeToConvert) then
lngSomething = CLng(strValue)
else
' WOOP! WOOP!
end if
Nasty, no? If there's a better way, though, I'd love to know it....
You could always do
on error resume next
lngSomething = CLng(strValue)
and then test for errors... but I mean, that's a REALLY ugly hack.
Paul
More information about the thelist
mailing list