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

[Shark8 <onewingedshark@gmail.com>]

On Feb 9, 3:50 pm, Hyman Rosen <hyro...@mail.com> wrote:
> On 2/9/2011 5:38 PM, Vinzent Hoefler wrote:
>
> OK, I know I'm sounding like a smart ass, but take my
> question seriously. There's an awful lot of castigation
> of C code (and coders) going on here, with complaints
> about "bugs on every line", but isn't that equally true
> of Ada code?

No, there are some errors in C that are flatly impossible
within Ada; one of my 'favorite' being the ability to put
an assignment int a conditional-test.

I realize that there are *SOME* possibly valid uses
thereof, but in my experience the overwhelming
majority of the time it's encountered it is the incorrect
formulation of a condition-test and needs/needed to
be corrected.

The reduction of *possible* errors necessarily means
that the purely-random chance of producing an
error-free program is increased.

> Doesn't every subprogram call potentially
> raise Storage_Error, and isn't that possibility usually
> ignored?

No, and no.
First, consider this:

Procedure main is
  Procedure Stub is begin null end Stub;
begin
Stub;
end main;

Where main is anagolus to C's main...
unless you truly ARE out of memory, in which case the
program-loader should itself give you the error, there is
enough memory for Stub because there was enough for
main, which was loaded and Stub is a part of main.

{There could be odd-compiler exceptions where this isn't true.}

Furthermore even though it is a general possibility that
any subprogram could raise storage_error, this is *NOT*
generally unaccounted for, the program halts and displays
just that error.

IE - In just the way that JAVA cannot triple-fault your system
with an un-handled exception because the JAVA-VM program
has a handler built-in to a) display the error and b) prevent the
exception from cascading into the OS, so to is the exception
system in Ada; instead of merrily chugging away the proper
message is displayed and thins are 'shut down' to save the
rest of the system.

> And in fact, don't Ada newbies run into this
> all the time, because they declare large arrays or
> records as local variables and run out the call stack?

That's an interesting question... it is an honest way to handle
something, arrays in particular, to throw out a message saying
"I don't have enough memory to do this!" and halt the program,
than say pretending that doesn't matter and allowing the
program to continue, no?

That beginners make the mistake of over-allocating memory is
not, in my thinking, a very valid complaint. If you're coming in
from a heavy math-background then the limitations {like the
finiteness of integer-types, or the [im]precision of floating types}
is certainly bothersome, but accurately reflect the limitations of
the underlying hardware. {Some languages, like Prolog, have no
real limit to the range of representable integers except
ALL OF MEMORY.}

On the other hand, someone coming in to CS from, say, high-
school would encounter the exact same problem of limitations
but with the added burdens of ignorance regarding, say, the
properties of numbers.

Ada offers the BEST combination I have seen between showing
the finite/limited nature of the computer, allowing/encouraging the
use of properties (sub-types like Natural & Positive), and
expressing it all in a high-level manner.

Java, as a counter-example strives to express things as "Objects,"
in a high-level uniform manner with abstraction and methods and
all that, but low-level {device-driver} it is not.

C (note I am not saying C++) is at the opposite end of the spectrum
where it focuses endlessly on the limitations of the hardware w/o
providing much in the way of abstraction: functions. C's "arrays" are
an interesting result of this; they really aren't arrays, just
pointers and
the item in the [] is an offset, and in C-compilers {at least one}
you
could say 4[array] instead of array[4] because that specific array-
element IS accessible as Array_base_Address + 4 and the '+' is
the same regardless of which side is which.

LISP, on the other-other hand is a sort of high-level emphasize-
the-properties type. Many mathematical functions are a fairly
straightforward translation, though the prefix-syntax is a bit odd.
As you can see the Fibonacci function[s] are a straightforward
translation of the math piecewise-function:
(defun fib (0) 1)
(defun fib (1) 1)
(defun fib (n)
    (+ (fib (- n 1)) (fib (- n 2)))
)
In this manner, LISP is almost the polar opposite of C; it is utterly
unconcerned about the interior-implementation and underlying
hardware.

If "newbies can easily create a whole memory-sized array" is
really that much of a problem, then LISP would be the answer.