Re: Unsigned Indexing (was: some other sad story)
From: Niklas Borson (niklasb_at_microsoft.com)
Date: 31 Dec 2003 15:58:28 -0800
firstname.lastname@example.org (Edward G. Nilges) wrote in message news:<email@example.com>...
> Programmer Dude <Chris@Sonnack.com> wrote in message news:<3FF1E368.22DC9488@Sonnack.com>...
> > "Edward G. Nilges" wrote:
> > > Good style happens to be fully independent of the limitations of
> > > any one language.
> > I'd agree with that, except for the "fully". Good code should
> > transcend the language as much as possible, but--as with any
> > expert speaker of a human language--an expert programmer also
> > knows the art and specialties of their language.
> Interesting thesis. Probably wrong.
> Anything Scott Fitzgerald said, and the way he said it, is fully
> translatable into French by a skilled translator who is able to "map"
> concepts. A great writer TRANSCENDS the limits of his language, like
> Tolstoy, to speak to the human condition.
Ah, but can "I scream for ice cream!" really be translated to
another language? :-)
> > > FYI, your code should not depend on the hardware.
> > You misunderstand. It doesn't--in any way--"depend on hardware".
> > It depends on "what is essentially a hardware effect (signedness
> > of integers)". Specifically, in this case, that an unsigned
> > integer will, when decremented from zero, "roll over" to its
> > highest (positive, obviously) value.
> Uh, this does not happen, as far as I know, on the CLR of .Net.
> Instead the number gets a special value. Which means that .Net might
> break your code.
The behavior described above is specified in the C and C++ standards
so Chris' code doesn't depend on any implementation-defined behavior.
If the code does break under some platform, then that platform does
not implement the C++ standard correctly.
With respect to the CLR, you're mistaken. For example, the following
C# program displays 4294967295 on my computer.
static void Main()
uint n = 0;
It's possible you were misled by the fact that unsigned integral
types are not CLS-compliant. This doesn't mean they don't work. It
just means they are not among the subset of types that *all* .NET
languages are expected to understand.
> > > Is your code portable?
> > Fully. C and C++ *require* by spec that unsigned integers behave
> > thus (regardless of what's happening under the hood).
> Hmm, this defeats the whole intent of "managed code" which is to
> prevent viruses and other unsafe code from exploiting a site. The
> execution future of managed code can be determined by a static
> inspection. But the C and C++ conventions in what I have called a
> normalized deviance demand the ability to deviate.
The static inspection you refer to is called verification. It's true
that C++ code compiled to IL is not verifiable (at least today), but
I don't see how unsigned types have any bearing on this. C# also has
unsigned types, yet is verifiable.
> Which is why C++ to this day is not fully "manageable" in .Net's
> sense, perhaps.
The intermediate language (IL) used by the CLR is flexible enough
that any C++ program can be compiled to IL. Such a program is loaded,
just-in-time compiled, and run by the CLR. So is it "managed"? The
program can also use and (through language extensions) define managed
(i.e., garbage collected) types. Now is it "managed"?
I think you'd have to say yes, it is managed. However, it is not
*verifiable*. This doesn't break the whole security model because
unverifiable code has to be highly trusted or the CLR will refuse
to run it.
So what is it about C++ that makes it unverifiable (at least today)?
Certainly not unsigned types. I think it has more to do with pointer
arithmetic and the way the free store works. After all, it is also
possible to make C# unverifiable using the unsafe keyword. And what
C# language feature does the unsafe keyword make available? You
guessed it: C-style pointers.