Lies in education [was Re: The "loop and a half"]

[Steve D'Aprano]

On Fri, 13 Oct 2017 11:48 pm, Gregory Ewing wrote:

> Steve D'Aprano wrote:
>> I wasn't questioning where the data came from, but how the compiler can
>> write to READ ONLY MEMORY which might not even be in the same continent as
>> the compiler that generated the code.
> 
> I thought it would be fairly obvious that by "put it in
> read-only memory" I meant "arrange for it to be in a
> location that is read-only at run time". Obviously it
> can't be read-only at *compile* time, just as a
> physical ROM can't be read-only at manufacture time.

No, its not obvious.

It is a lot less obvious than my reference to ROM being burnt into hardware at
a factory, which you responded to with the irrelevant observation that the
data originated from a compiler.

Sure, some data in ROMs might come from a compiler -- and some of it might
not. Suppose a ROM contains a list of the names of the computer's developers
(as some Mac ROMs did). It would be an abuse of language to say 

    "The text editor writes to the ROM"

and it is equally an abuse to say that the compiler writes to ROM just because
the data burned into the chip is some sort of compiled object code. As Peter
Holzer points out, the compiler likely writes to an object file, not the ROM,
and as I pointed out, the process manufacturing the ROM might not even be in
the same continent as the compiler.

So when you talk about Read Only Memory, you're apparently not actually
talking about actual Read Only Memory (ROM).

Something has to write this data to "read only memory", and it must be able to
do it over and over and over again, each time the program runs. How is this
*read only*? It's not even "Write Once, Read Many" (WORM). What sort of read
only memory can be written to over and over again?

(This is not a rhetorical question.)

It seems to me that you're not talking about ROM at all, but ordinary RAM.
Then what do you mean by "read only"? A block of memory with a flag that
says "unprivileged processes are prohibited from writing here"?

(That's also not a rhetorical question.)

Since the compiler is an unprivileged process, how can it write to memory that
unprivileged processes cannot write to? I'm guessing that it can't. Can it?
If not, then its probably some privileged process (part of the OS?) which
does the writing. Am I close?

(Still not a rhetorical question.)

Earlier you said:

    If the compiler can tell where p is initially pointing, it could
    put the pointer in read-only memory.

i.e. that you believe it is the *compiler* doing the writing. If that's not
actually what you meant, then what you meant is not sufficiently clear.


-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.