Re: How do I write directly to a memory address?

[Ludovic Brenta <ludovic@ludovic-brenta.org>]

Hyman Rosen wrote:
> Writers here said that they look
> at every line of C code and see bugs. I am telling you that I
> look at every line of Ada and I see bugs - you cannot tell me
> that a simple subprogram call will work, because it may crash
> the program instead by raising Storage_Error.

FTR, I never said I saw a bug on every line of C code. I said: every
time I look at a C *code* I see a bug.

And I am actually flattered that the only "bug" you could think of
when looking at Ada code was the possibility of a Storage_Error.  This
is a Good Thing.  In C, you can't get a Storage_Error because C lacks
exception; instead you get undefined behavior.  And there are a *lot*
more ways that C can hide bugs than Ada.  This is why I maintain that
C is bad for everyone's health.  Ada is not perfect but it's the best
I've come across so far (and I've come across many languages).  SPARK
is, of course, even more secure but unfortunately not applicable to
all programming needs.

> What I am trying to make you see is that C code does not have
> bugs on every line, just as Ada code does not have bugs on
> every line. You look at C and say "What if the pointer is
> null, or the index is out of range?" I tell you that it is no
> more justified to think that each time than it is for me to
> look at Ada code and say "What if this subprogram call raises
> Storage_Error?"
>
> It is true that some C code will contain
> pointer and index errors, just as some Ada code will raise
> Storage_Error. But it is a bad mistake to assume that this
> is true everywhere in the code.

You are wrong because the C program can *also* overflow its stack or
heap and you *also* have to worry about that, just like in Ada; but
you get no help from the C language or run-time library to detect
these classes of bug.  At least Ada makes stack overflows visible to
you.  And you can take advantage of Ada's type system to make many
other bugs impossible (e.g. array bounds, null pointer, double-free,
etc.) such that you *don't* have to worry about them.  In other words,
the set of bugs you must look out for in C is a superset of those you
have to look out for in Ada *and* the possible manifestations of these
bugs are usually undefined in C whereas they are bounded errors (i.e.
exceptions) in Ada. This is why Ada is so vastly superior to C.

When looking at C code, if you don't constantly ask yourself "hat if
the pointer is null, or the index is out of range?" then I am quite
worried at the resulting quality of your code.

> Right. You are inordinately proud of Ada's ability to capture
> numeric ranges in its type system.

I'm not proud of Ada's numeric ranges; I am proud to have chosen the
proper tool for the job, and every time Ada's numeric ranges has saved
my skin in the past has reinforced my confidence in it. You don't seem
to even grasp how useful these numeric ranges are; they are so useful
that, after my years of experience using 20+ languages, I would refuse
to consider using a language that doesn't have them.

> Because [C and C++] are both good and capable languages with attractive,
> idiomatic, and powerful ways of doing certain things, and I like
> them. And partly because I'm an old fogey who learned C in 1980.

No, they are not good and capable languages.  They are bad and
dangerous languages.  The only redeeming feature of C was that it was
easy to implement (but so were Pascal and Modula).  C++ does not even
have that excuse.

--
Ludovic Brenta.