[thelist] ASP: DIM var AS ??

Paul Cowan evolt at funkwit.com
Wed Jul 2 19:37:15 CDT 2003

Chris W Parker wrote:

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)
        ' 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.


More information about the thelist mailing list