Signed word lengths and indexes

[Ellery Newcomer]

On 06/14/2010 05:48 PM, Walter Bright wrote:
> bearophile wrote:
>> I have found a Reddit discussion few days old:
>> http://www.reddit.com/r/programming/comments/cdwz5/the_perils_of_unsigned_iteration_in_cc/
>>
>>
>>
>> It contains this, that I quote (I have no idea if it's true), plus
>> follow-ups:
>>
>>> At Google using uints of all kinds for anything other than bitmasks or
>>> other inherently bit-y, non computable things is strongly
>>> discouraged. This
>>> includes things like array sizes, and the warnings for conversion of
>>> size_t
>>> to int are disabled. I think it's a good call.<
>>
>> I have expressed similar ideas here:
>> http://d.puremagic.com/issues/show_bug.cgi?id=3843
>>
>> Unless someone explains me why I am wrong, I will keep thinking that
>> using
>> unsigned words to represent lengths and indexes, as D does, is wrong and
>> unsafe, and using signed words (I think C# uses ints for that purpose)
>> in D
>> is a better design choice.
>
> D provides powerful abstractions for iteration; it is becoming less and
> less desirable to hand-build loops with for-statements.

Ooo ooo, can we remove it?

>
> As for "unsafe", I think you need to clarify this, as D is not memory
> unsafe despite the existence of integer over/under flows.

I think the problem is people don't generally think of fixnums as 
fixnums when they use them.

Just recently I was reading about some security vulnerabilities in ruby 
from a few years ago which were caused when whoever wrote the underlying 
C didn't take integer overflow into consideration.

What I take away from this anecdote is that it's that much harder to 
write trustworthy code in D. As always, the existence of issue 259 
doesn't help matters.

And from personal experience, I submit that checking for overflow is 
very painful to do manually (I tried to write a modular arithmetic lib 
for fixnums - and gave up rather quickly). Want language support (or 
library support, I don't care).

>
>
>> In a language as greatly numerically unsafe as D (silly C-derived
>> conversion
>> rules,
>
> Actually, I think they make a lot of sense, and D's improvement on them
> that only disallows conversions that lose bits based on range
> propagation is far more sensible than C#'s overzealous restrictions.
>
>
>> fixed-sized numbers used everywhere on default, no runtime numerical
>> overflows) the usage of unsigned numbers can be justified inside bit
>> vectors,
>> bitwise operations, and few other similar situations only.
>>
>> If D wants to be "a systems programming language. Its focus is on
>> combining
>> the power and high performance of C and C++ with the programmer
>> productivity
>> of modern languages like Ruby and Python." it must understand that
>> numerical
>> safety is one of the not secondary things that make those languages as
>> Ruby
>> and Python more productive.
>
> I have a hard time believing that Python and Ruby are more productive
> primarily because they do not have an unsigned type.

They're more productive because their built in number types aren't 
fixnums. That's a nice large class of errors that don't exist in those 
languages.

>
> Python did not add overflow protection until 3.0, so it's very hard to
> say this crippled productivity in early versions.
> http://www.python.org/dev/peps/pep-0237/
>
> Ruby & Python 3.0 dynamically switch to larger integer types when
> overflow happens. This is completely impractical in a systems language,
> and is one reason why Ruby & Python are execrably slow compared to
> C-style languages.