int/long unification hides bugs

[Sam Holden]

On Tue, 26 Oct 2004 20:14:49 -0700 (PDT),
	kartik vaddadi <kartick_vaddadi at yahoo.com> wrote:
>
> --- Josiah Carlson <jcarlson at uci.edu> wrote:
>
>> 
>> kartick_vaddadi at yahoo.com (kartik) wrote:
>> 
>> > integers are used in different ways from strings.
>> i may expect file
>> > paths to be around 100 characters, and if i get a
>> 500-character path,
>> > i have no problem just because of the length. but
>> if a person's age is
>> > 500 where i expect it to be less than 100, then
>> **definitely**
>> > something's wrong.
>> 
>> So *you* need to do bounds checking.
>
> do you check every assignment for bounds? can you?
> overflow errors catch bugs when you dont do the
> checks. 

I don't check every assignment because in the vast majority of the time
I don't want overflow to happen I would much rather the computer just
use more space to store the number. If overflow happens the program
doesn't work and has to be modified to handle the larger data - if
python can make it "just work" then wonderful!

For those operations where bounds do matter then yes I do check them.
Relying on overflow has never been option since *never* have my bounds
happened to be exactly the same as those of the int type on whatever
machine/language I was using. Depending on the situation I may 
check each operation or I may just check the final result.

An overflow at 2^32-1 is never going to catch that one of the
"marks out of 100" is 103, so overflow will *never* catch bugs
for that code.

It would be a real hassle if I happened to have in the order
of 2^26 students and I couldn't calculate the average mark
because of a useless overflow error (ignoring that marking
all those exams would be slightly more of a problem :)

>> > as i look at my code, i rarely have an issue with
>> string sizes, but if
>> > an integer variable gets very large (say > 2**31
>> or 2**63), it
>> > generally reflects a bug in my code.
>> 
>> And you should check that, and not rely on a
>> misfeature and a mistake. 
>
> why do u want me to check something that the language
> can do? for precisely this reason, i consider this not
> to be a misfeature or a mistake.

Because in the majority of cases the language doing it makes life more
difficult.

You can always use a version of python which does what you want, or
write your own language which arbitrary limits on things like number
sizes and string lengths.

The rest of us living in the real world will be happy with a
language which provides correct behaviour with less code.

>
>> I don't rely on overflow errors. [...]
>> I prefer to check my variables when I rely on them.
>
> i never talked about *relying* on overflow errors to
> ensure the correctness of code. it's only a mechanism
> that catches bugs in some cases - & that's valuable.

That's not valuable at all. It encourages a "I won't bother doing bounds
checking on my operations since if I stuff up the language *might* catch
it if I get lucky and crash my program" style of programming that you
seem fond of.

Better to do bounds checking that will *always* catch it.

I take it you will never move to a 64 bit architecture since then your
"valuable" overflow errors will "catch bugs" in even fewer cases.

-- 
Sam Holden