By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,361 Members | 1,988 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,361 IT Pros & Developers. It's quick & easy.

Write only memory

P: n/a
In C, we have read-only memory (const), read/write memory
(normal data), and write only memory.

Let's look at the third one in more detail.

Write only memory is a piece of RAM that can only
be written to, since its contents are undefined.

The program is allocating a new piece of data, and
the previous contents aren't relevant. This memory
is generated by malloc and friends, or allocated
statically by the compiler by making the processor
increase the stack area at the entry of the function.

When you read from write only memory (you use an
uninitialized variable) the behavior is undefined,
i.e. it is declared a big mistake.

It is big because the consequences are random. When
a value is read from that memory locations, its contents
are random. We know that if we have rebooted maybe the
OS has just cleaned up and this memory is not quite
random, it is mostly zero. If the machine is running
since a while however, the contents are probably
whatever data was written to that address before, in
another program.

The symptoms are very vague. Programs that run at the
start stop working, a program that has just run crashes,
symptoms that *could* be related to this program or not.

Confusing symptoms.

This confusion is because of the random nature of the
data being introduced in the program.

The great remedy of course, is to have default values
for all local variables and set them at the start. This
doesn't eliminate all bugs, but at least
eliminates those of reading from write only memory.

As a first approach:
Data *Function(Data *d, index i)
{
Data workCopy;
DataIndex di;
etc...

memset(&workCopy,0,sizeof(Data));
memset(&di, 0, sizeof(DataIndex));
etc...
}

Shorter would be:
Data *Function(Data *d, index i)
{
Data workCopy={0};
DataIndex di={0};
etc...

}

This already much better, but it is still bothersome
if you forget one.

Even better would be if we would just write:

_Pragma(Stdc,Zeroinit,Function)

meaning that in the given function all local
data should be zeroed before use at function
entry.

But that is still too long...

Couldn't we just decide that by default all locals
are zeroed at entry of the function?

Only when you write:

_Pragma(Stdc, Nozeroinit, function)

would be the zeroing of memory be avoided.

I think that would be the best. Not to write
anything at all. This would slow software a bit,
(maybe) but for *many* applications running
in PCs today that would not do any real
performance lost.

Zero is used as default value in many situations,
pointers couldn't by chance destroy another data item
since even uninitialized pointers would be NULL.

How nice. This would mean also no change to
existing programs. They would just run a few
microseconds slower and nobody would care.

The data must be brought to the L1 cache anyway,
and zeroing locals ensures that they do not
provoke a processor L1 cache fault later within
the code of the function. A burst mode
can be probably used if present. This reduces
the cost of each cache failure: all at once.

Most locals space is small anyway.

The problems arising from reading write-only
memory would be restricted to hard traps in
the program, very easy to pinpoint to a
specific line of code.

In most implementations a NULL dereference
traps, and the error is pinpointed exactly
where it arises. With bogus values in a
pointer there is some chance that the pointer
destroys other data structures. Using NULL
there is none. The integrity of the program itself
is not destroyed.
Nov 14 '05 #1
Share this Question
Share on Google+
18 Replies


P: n/a
On Thu, 14 Oct 2004 23:32:05 +0200, jacob navia wrote:
In C, we have read-only memory (const), read/write memory
(normal data), and write only memory.

Let's look at the third one in more detail.

Write only memory is a piece of RAM that can only
be written to, since its contents are undefined.
Funny... I thought write-only memory was /dev/null.

(Or the programmer after a couple beers. ;-))

The program is allocating a new piece of data, and
the previous contents aren't relevant. This memory
is generated by malloc and friends, or allocated
statically by the compiler by making the processor
increase the stack area at the entry of the function.
Or however the compiler and hardware like to do it. But this is
irrelevant.

When you read from write only memory (you use an
uninitialized variable) the behavior is undefined,
i.e. it is declared a big mistake.

It is big because the consequences are random. When
a value is read from that memory locations, its contents
are random. We know that if we have rebooted maybe the
OS has just cleaned up and this memory is not quite
random, it is mostly zero. If the machine is running
since a while however, the contents are probably
whatever data was written to that address before, in
another program.

The symptoms are very vague. Programs that run at the
start stop working, a program that has just run crashes,
symptoms that *could* be related to this program or not.

Confusing symptoms.

This confusion is because of the random nature of the
data being introduced in the program.

The great remedy of course, is to have default values
for all local variables and set them at the start. This
doesn't eliminate all bugs, but at least
eliminates those of reading from write only memory.
Yes, this is why some debuggers will initialize memory of this sort to a
known but unusual value, to turn Heisenbugs of this kind into Bohr bugs.
0xDEADBEEF and 0xCAFEBABE are common on 32-bit systems which have
debuggers with this function.

[bobbit]
This already much better, but it is still bothersome
if you forget one.

Even better would be if we would just write:

_Pragma(Stdc,Zeroinit,Function)

meaning that in the given function all local
data should be zeroed before use at function
entry.
I think all pragmas look like preprocessor directives. That is, it should
be written as:

#pragma (...)

But that is still too long...
Not for me. Not if I want my compiled code to not waste its time zeroing
RAM I'll never accidentally access, because I enforce a modicum of hygiene
on my code.

Couldn't we just decide that by default all locals
are zeroed at entry of the function?
This loses when a function needs to declare really large locals and the
programmer is smart enough to not access them before they've been written
to. Your CPU burns clock cycles and expensive RAM access time for no good
reason.

Only when you write:

_Pragma(Stdc, Nozeroinit, function)

would be the zeroing of memory be avoided.
/This/ is too much typing.

I think that would be the best. Not to write
anything at all. This would slow software a bit,
(maybe) but for *many* applications running
in PCs today that would not do any real
performance lost.
Bah. C isn't (just) for PCs. C is for embedded devices and
high-performance systems that don't want to waste time looking out for
incompetent programmers.

Zero is used as default value in many situations,
pointers couldn't by chance destroy another data item
since even uninitialized pointers would be NULL.
No. Wrong. NULL != 0x00000000 on all systems. Programmers who think it is
get bitten.

How nice. This would mean also no change to
existing programs. They would just run a few
microseconds slower and nobody would care.
Wrong. Programs controlling things like heart-lung machines and
supercomputers could run noticeably slower, and this is not always
acceptable.

The data must be brought to the L1 cache anyway,
and zeroing locals ensures that they do not
provoke a processor L1 cache fault later within
the code of the function. A burst mode
can be probably used if present. This reduces
the cost of each cache failure: all at once.
"The fool in his heart thinks `All the world's a PC.'"

Most locals space is small anyway.
Not always. It may be quite large if the function is doing lots of vector
or matrix math, as in graphical applications.

The problems arising from reading write-only
memory would be restricted to hard traps in
the program, very easy to pinpoint to a
specific line of code.
This is why you have a debugger. (This is also why you have eyes and a
brain, but apparently those cannot be safely assumed anymore.)

In most implementations a NULL dereference
traps, and the error is pinpointed exactly
where it arises. With bogus values in a
pointer there is some chance that the pointer
destroys other data structures. Using NULL
there is none. The integrity of the program itself
is not destroyed.


This loses on systems without an MMU, and an embedded system usually does
not need an MMU. Again, thinking the world is a PC is pretty stupid.

Nov 14 '05 #2

P: n/a
>This loses when a function needs to declare really large locals and the
programmer is smart enough to not access them before they've been written
to. Your CPU burns clock cycles and expensive RAM access time for no good
reason.


Not to mention that a lot of errors come from wrong uses of malloc(). Of
course this is a lot like calloc()...

--
(anonymous)
Nov 14 '05 #3

P: n/a
Lamb9bert wrote:
This loses when a function needs to declare really large locals and the
programmer is smart enough to not access them before they've been written
to. Your CPU burns clock cycles and expensive RAM access time for no good
reason.

Not to mention that a lot of errors come from wrong uses of malloc(). Of
course this is a lot like calloc()...


Hopefully, two things are true:

1. calloc() is implemented intelligently at the machine-code level, and
so can do a very fast zeroing of core because it always knows precisely
how much core it needs to wipe. A compiler, at least one that implements
VLAs, doesn't always know this.

2. The programmer doesn't use calloc() without good reason. The
programmer /especially/ doesn't use calloc() because he thinks it will
NULL an array of pointers. (This is in the FAQ, I think.)

Of course, the first one is QoI, and the second one is QoP. ;)
Nov 14 '05 #4

P: n/a
Chris Barts wrote:
The great remedy of course, is to have default values
for all local variables and set them at the start. This
doesn't eliminate all bugs, but at least
eliminates those of reading from write only memory.

Yes, this is why some debuggers will initialize memory of this sort to a
known but unusual value, to turn Heisenbugs of this kind into Bohr bugs.
0xDEADBEEF and 0xCAFEBABE are common on 32-bit systems which have
debuggers with this function.


lcc-win32 uses 0xFFFA5A5A
[bobbit]

This already much better, but it is still bothersome
if you forget one.

Even better would be if we would just write:

_Pragma(Stdc,Zeroinit,Function)

meaning that in the given function all local
data should be zeroed before use at function
entry.

I think all pragmas look like preprocessor directives. That is, it should
be written as:

#pragma (...)

C99 makes _Pragma and #pragma equivalent
But that is still too long...

Not for me. Not if I want my compiled code to not waste its time zeroing
RAM I'll never accidentally access, because I enforce a modicum of hygiene
on my code.

Couldn't we just decide that by default all locals
are zeroed at entry of the function?

This loses when a function needs to declare really large locals and the
programmer is smart enough to not access them before they've been written
to. Your CPU burns clock cycles and expensive RAM access time for no good
reason.

Only when you write:

_Pragma(Stdc, Nozeroinit, function)

would be the zeroing of memory be avoided.

/This/ is too much typing.

This could be replaced with a compile time switch that would be global
I think that would be the best. Not to write
anything at all. This would slow software a bit,
(maybe) but for *many* applications running
in PCs today that would not do any real
performance lost.

Bah. C isn't (just) for PCs. C is for embedded devices and
high-performance systems that don't want to waste time looking out for
incompetent programmers.


Even the best programmers do make mistakes.
Of course it never happens to you...
How nice. This would mean also no change to
existing programs. They would just run a few
microseconds slower and nobody would care.

Wrong. Programs controlling things like heart-lung machines and
supercomputers could run noticeably slower, and this is not always
acceptable.


Mmm I would prefer a heart-lung machine with no bugs
pleeeeeeeeeeeze...

This "speed at any price" attitude is widespred. Todays
embedded systems use CPUs that leave PCs behind. The
Analog Devices DSPs are 32 bit for instance, and feature
an impresive speed, very comparable to PCs.
The data must be brought to the L1 cache anyway,
and zeroing locals ensures that they do not
provoke a processor L1 cache fault later within
the code of the function. A burst mode
can be probably used if present. This reduces
the cost of each cache failure: all at once.

"The fool in his heart thinks `All the world's a PC.'"


Very few modern processor do not have a cache. Yes,
I know that there are other things that PCs but I am
speaking about a PC environment.

This whole discussion brings us to several possible
modes of execution in C.

You would have a SAFE mode with many kinds of checks,
and a FAST mode, where those checks would be normally
disabled.

There is no "one fits all" solution, and splitting the
run time into several would be better.

Speed is only one of the factors in software. There are
many others like security, robustness, etc, that in
many applications are more important than "speed".
Nov 14 '05 #5

P: n/a
jacob navia wrote:
In C, we have read-only memory (const), read/write memory
(normal data), and write only memory.

Let's look at the third one in more detail.

Write only memory is a piece of RAM that can only
be written to, since its contents are undefined.
Make that 'should only be written to'. There's no reason you can't use
unsigned chars to access the location and print what you find there.

The program is allocating a new piece of data, and
the previous contents aren't relevant. This memory
is generated by malloc and friends, or allocated
statically by the compiler by making the processor
increase the stack area at the entry of the function.

When you read from write only memory (you use an
uninitialized variable) the behavior is undefined,
i.e. it is declared a big mistake.

It is big because the consequences are random. When
a value is read from that memory locations, its contents
are random.
Many compilers do a decent job at data flow analysis and catch the
obvious uses of uninitialized memory. There are both commercial and
free static data analysis tools (splint, pc-lint, etc), as well as
runtime analysis tools (valgrind, purify, etc) you can use.
Additionally, some debug runtimes initialize uninitialized memory with
sentinel values to aid debugging.
We know that if we have rebooted maybe the
OS has just cleaned up and this memory is not quite
random, it is mostly zero. If the machine is running
since a while however, the contents are probably
whatever data was written to that address before, in
another program.

The symptoms are very vague. Programs that run at the
start stop working, a program that has just run crashes,
symptoms that *could* be related to this program or not.
Not usually these days, unless you're running on an embedded system (or
a legacy OS). Because of security implications, all protected mode
operating systems I know of only supply zero-filled pages to user
processes. Usually this is done with a kernel thread that executes as
part of the idle loop.

Within a process, sure, you'll get re-used pages, but this is only
within a process' lifetime, and really has nothing to do with whether or
not the machine has been running for a while or has just been rebooted.

Confusing symptoms.

This confusion is because of the random nature of the
data being introduced in the program.

The great remedy of course, is to have default values
for all local variables and set them at the start. This
doesn't eliminate all bugs, but at least
eliminates those of reading from write only memory.
And this is certainly enforcable with static analysis tools, if that's
your cup of tea. No need to get fancy.

As a first approach:
Data *Function(Data *d, index i)
{
Data workCopy;
DataIndex di;
etc...

memset(&workCopy,0,sizeof(Data));
memset(&di, 0, sizeof(DataIndex));
etc...
}

Shorter would be:
Data *Function(Data *d, index i)
{
Data workCopy={0};
DataIndex di={0};
etc...

}

This already much better, but it is still bothersome
if you forget one.

Even better would be if we would just write:

_Pragma(Stdc,Zeroinit,Function)
I don't think it's better.

meaning that in the given function all local
data should be zeroed before use at function
entry.

But that is still too long...

Couldn't we just decide that by default all locals
are zeroed at entry of the function?

Only when you write:

_Pragma(Stdc, Nozeroinit, function)

would be the zeroing of memory be avoided.
Once again, not better.

I think that would be the best. Not to write
anything at all. This would slow software a bit,
(maybe) but for *many* applications running
in PCs today that would not do any real
performance lost.
C is mostly used where the impact would be higher than you expect. I
don't want my python and perl interpreters compiled with this. I don't
want my device drivers compiled with this.

In the embedded systems I work on, I don't want anything like this.
Especially in the more resource-constrained ones, which, believe it or
not, are becoming more and more prevalent.

Zero is used as default value in many situations,
pointers couldn't by chance destroy another data item
since even uninitialized pointers would be NULL.

How nice. This would mean also no change to
existing programs. They would just run a few
microseconds slower and nobody would care.
Unless said system does not have a MMU and you blast away the interrupt
vector table or something else important. Not to mention that NULL does
not necessarily mean 'all bits zero'.

The data must be brought to the L1 cache anyway,
and zeroing locals ensures that they do not
provoke a processor L1 cache fault later within
the code of the function. A burst mode
can be probably used if present. This reduces
the cost of each cache failure: all at once.
What? L1's come in a variety of shapes and sizes, if there's one at
all. And why pay up front for branches you might not take, for storage
you might not use. It doesn't make sense. It introduces cache pressure
and potentially causes problems where writes block reads and the write
buffer isn't deep.

Most locals space is small anyway.
Yeah, sure.

The problems arising from reading write-only
memory would be restricted to hard traps in
the program, very easy to pinpoint to a
specific line of code.
So tell me, how do you get there from here? Now you're talking about
data type trap representations. Some types are guaranteed not to have
trap representations. If I read from an uninitialized unsigned char
type, I cannot possibly cause the program to trap.

In most implementations a NULL dereference
traps, and the error is pinpointed exactly
where it arises. With bogus values in a
pointer there is some chance that the pointer
destroys other data structures. Using NULL
there is none. The integrity of the program itself
is not destroyed.


Whatever. The integrity of a program chasing around random pointers is
not likely to be saved despite your best intentions.
Mark F. Haigh
mf*****@sbcglobal.net

Nov 14 '05 #6

P: n/a
jacob navia wrote:
<snip>
lcc-win32 uses 0xFFFA5A5A
That's fantastic.

<snip>

This "speed at any price" attitude is widespred. Todays
embedded systems use CPUs that leave PCs behind. The
Analog Devices DSPs are 32 bit for instance, and feature
an impresive speed, very comparable to PCs.


Go do your homework, son-- you obviously don't have a clue. Or are you
one of ERT's alter-egos?

Mark F. Haigh
mf*****@sbcglobal.net
Nov 14 '05 #7

P: n/a
jacob navia wrote:

In C, we have read-only memory (const), read/write memory
(normal data), and write only memory.

Let's look at the third one in more detail.

Write only memory is a piece of RAM that can only be written to

.... snip ...

Many moons ago, when Sylvania still made memory chips, they
produced such a device and supplied a data sheet for it. You might
find it on the web somewhere.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 14 '05 #8

P: n/a
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

jacob navia wrote:
| Chris Barts wrote:
|
|> jacob navia wrote:
|>> Even better would be if we would just write:
|>>
|>> _Pragma(Stdc,Zeroinit,Function)
|>>
|>> meaning that in the given function all local
|>> data should be zeroed before use at function
|>> entry.
|>
|>
|>
|> I think all pragmas look like preprocessor directives. That is, it should
|> be written as:
|>
|> #pragma (...)
|>
| C99 makes _Pragma and #pragma equivalent

I did not know that.

|>> Only when you write:
|>>
|>> _Pragma(Stdc, Nozeroinit, function)
|>>
|>> would be the zeroing of memory be avoided.
|>
|>
|>
|> /This/ is too much typing.
|>
| This could be replaced with a compile time switch that would be global

Then conformant programs could have wildly variant behaviors depending
on something fully outside the source code. I think a Standardized
language should minimize things like that.

|
|>
|>> I think that would be the best. Not to write
|>> anything at all. This would slow software a bit,
|>> (maybe) but for *many* applications running
|>> in PCs today that would not do any real
|>> performance lost.
|>
|>
|>
|> Bah. C isn't (just) for PCs. C is for embedded devices and
|> high-performance systems that don't want to waste time looking out for
|> incompetent programmers.
|>
|
| Even the best programmers do make mistakes.
| Of course it never happens to you...

I have never made this kind of error, no. I do, of course, make
mistakes, but I don't expect the compiler to hold my hand. I have a very
nice debugger to step through my code, and I have a nicer brain to
reason things through.

|
|>
|>> How nice. This would mean also no change to
|>> existing programs. They would just run a few
|>> microseconds slower and nobody would care.
|>
|>
|>
|> Wrong. Programs controlling things like heart-lung machines and
|> supercomputers could run noticeably slower, and this is not always
|> acceptable.
|>
|
| Mmm I would prefer a heart-lung machine with no bugs
| pleeeeeeeeeeeze...

How about a heart-lung machine that always works fast enough to keep
your heart and/or lungs going? And is still cheap enough for your
hospital to afford?

Plus, your scheme will not catch many, or even most, bugs. Programmers
writing software for essential systems should be experienced enough to
not need your proposed modifications.

|
| This "speed at any price" attitude is widespred. Todays
| embedded systems use CPUs that leave PCs behind. The
| Analog Devices DSPs are 32 bit for instance, and feature
| an impresive speed, very comparable to PCs.

Uh, what? Embedded systems are more cost-conscious than PCs, and they
are usually more heat- and power-conscious as well. (Speed usually ups
both power consumption and heat production, something that is often
unacceptable in embedded systems.)

And DSPs are something completely different.

|>
|> "The fool in his heart thinks `All the world's a PC.'"
|>
|
| Very few modern processor do not have a cache. Yes,
| I know that there are other things that PCs but I am
| speaking about a PC environment.

And here, again, you prove that you should /not/ be proposing
modifications to Standard C. C is widely used in non-PC environments,
non-workstation environments, and even non-hosted environments. /All/
modifications to Standard C must be reviewed with that firmly in mind.

[snip]

| Speed is only one of the factors in software. There are
| many others like security, robustness, etc, that in
| many applications are more important than "speed".

This is perhaps the only intelligent comment you've had so far.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBb5uQBsEyCHtFPhsRAmegAJ9wW9Ugnq8Eb8VM9MkonR X17g2QFQCeP2Pu
2PO/fPsjuajy1VCqX9d1knA=
=3hcm
-----END PGP SIGNATURE-----
Nov 14 '05 #9

P: n/a
jacob navia <ja***@jacob.remcomp.fr> writes:
In C, we have read-only memory (const), read/write memory
(normal data), and write only memory.

Let's look at the third one in more detail.

Write only memory is a piece of RAM that can only
be written to, since its contents are undefined.


I find your terminology confusing and misleading.

Read-only memory is memory that can only be read, not written. (How
and whether this is enforced is another question.)

Read/write memory is memory that can be either read or written;
presumably reading gives you the last value written to it.

In both cases, the memory remains read-only or read/write
indefinitely, regardless of what you do with it.

What you call "write only memory" is memory that *should* not be read
because it hasn't been initialized. Once you initialize it, it
becomes read/write memory. Calling it write-only implies a concept
analagous to read-only and read/write.

Just call it what it is: uninitialized memory.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #10

P: n/a
On Thu, 14 Oct 2004 23:32:05 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote:
In C, we have read-only memory (const), read/write memory
(normal data), and write only memory.
The last doesn't exist.
Let's look at the third one in more detail.
Tricky, since it doesn't exist.
Write only memory is a piece of RAM that can only
be written to, since its contents are undefined.


No, thats read/write memory that you've not yet initialised. Different
animal.

Your definition of write-only is asymmetric with your definition of
read-only, which is a nono. (I'm assuming you mean constants by that. If
not, then you have no argument at all.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #11

P: n/a
Groovy hepcat jacob navia was jivin' on Thu, 14 Oct 2004 23:32:05
+0200 in comp.lang.c.
Write only memory's a cool scene! Dig it!
In C, we have read-only memory (const), read/write memory
(normal data), and write only memory.
Nonsense! In C we have const qualified objects and objects that are
not const qualified. We have objects that are modifiable and objects
(such as string literals) which, whether const qualified or not, may
not be modifiable. There is no such thing as "write only memory".
Let's look at the third one in more detail.

Write only memory is a piece of RAM that can only
be written to, since its contents are undefined.
Piffle!
The program is allocating a new piece of data, and
the previous contents aren't relevant. This memory
is generated by malloc and friends, or allocated
statically by the compiler by making the processor
increase the stack area at the entry of the function.
Complete and utter nonsense! There ain't no sech animal as a stack
in the C language. And memory allocated by malloc() can be read. It
just causes undefined behaviour if you do so before putting useful
values into it first. The same goes for any object, not just
dynamically allocated ones.
When you read from write only memory (you use an
uninitialized variable) the behavior is undefined,
i.e. it is declared a big mistake.

It is big because the consequences are random. When
a value is read from that memory locations, its contents
are random. We know that if we have rebooted maybe the
OS has just cleaned up and this memory is not quite
random, it is mostly zero. If the machine is running
since a while however, the contents are probably
whatever data was written to that address before, in
another program.

The symptoms are very vague. Programs that run at the
start stop working, a program that has just run crashes,
symptoms that *could* be related to this program or not.
Do you know of any implementation which displays such simptoms as a
result of reading an uninitialised object? The most common symptom is
spurious values being displayed by the program (based on reading
spurious values from uninitialised objects).
Confusing symptoms.

This confusion is because of the random nature of the
data being introduced in the program.

The great remedy of course, is to have default values
for all local variables and set them at the start. This
This is not always necessary. Some people like to do that, but not
everyone.
doesn't eliminate all bugs, but at least
eliminates those of reading from write only memory.
No such thing!
As a first approach:
Data *Function(Data *d, index i)
{
Data workCopy;
DataIndex di;
etc...

memset(&workCopy,0,sizeof(Data));
memset(&di, 0, sizeof(DataIndex));
etc...
}

Shorter would be:
Data *Function(Data *d, index i)
{
Data workCopy={0};
DataIndex di={0};
etc...
}

This already much better, but it is still bothersome
if you forget one.

Even better would be if we would just write:

_Pragma(Stdc,Zeroinit,Function)

meaning that in the given function all local
data should be zeroed before use at function
entry.

But that is still too long...

Couldn't we just decide that by default all locals
are zeroed at entry of the function?
No, we couldn't. The C language does not require it, and it may slow
some programs down.
Only when you write:

_Pragma(Stdc, Nozeroinit, function)

would be the zeroing of memory be avoided.

I think that would be the best. Not to write
anything at all. This would slow software a bit,
(maybe) but for *many* applications running
in PCs today that would not do any real
performance lost.

Zero is used as default value in many situations,
pointers couldn't by chance destroy another data item
since even uninitialized pointers would be NULL.

How nice. This would mean also no change to
existing programs. They would just run a few
microseconds slower and nobody would care.

The data must be brought to the L1 cache anyway,
Nonsense! The C language does not define "L1 cache".
and zeroing locals ensures that they do not
provoke a processor L1 cache fault later within
the code of the function. A burst mode
The C language does not define "burst mode".
can be probably used if present. This reduces
the cost of each cache failure: all at once.

Most locals space is small anyway.

The problems arising from reading write-only
memory would be restricted to hard traps in
the program, very easy to pinpoint to a
specific line of code.

In most implementations a NULL dereference
traps, and the error is pinpointed exactly
where it arises. With bogus values in a
pointer there is some chance that the pointer
destroys other data structures. Using NULL
there is none. The integrity of the program itself
is not destroyed.


And what is the point of all this tripe?

--

Dig the even newer still, yet more improved, sig!

http://alphalink.com.au/~phaywood/
"Ain't I'm a dog?" - Ronny Self, Ain't I'm a Dog, written by G. Sherry & W. Walker.
I know it's not "technically correct" English; but since when was rock & roll "technically correct"?
Nov 14 '05 #12

P: n/a
jacob navia wrote:
When you read from write only memory (you use an
uninitialized variable) the behavior is undefined,
i.e. it is declared a big mistake.


The last time that I discussed this on comp.std.c,
they told me that an object with an indeterminate value,
such as a freed pointer or even an uninitialized object,
could be read as an array of unsigned char.

--
pete
Nov 14 '05 #13

P: n/a
pete wrote:

jacob navia wrote:
When you read from write only memory (you use an
uninitialized variable) the behavior is undefined,
i.e. it is declared a big mistake.


The last time that I discussed this on comp.std.c,
they told me that an object with an indeterminate value,
such as a freed pointer or even an uninitialized object,
could be read as an array of unsigned char.


A kind of memory that changes it's status after a write,
is not consistent with what
"read-only memory (const), read/write memory"
means.

What you've done by coining "write only" is that you have attempted
to classify memory based on whether it has an indeterminate
value according to the object's declared type, and you've got it wrong.

--
pete
Nov 14 '05 #14

P: n/a
Peter Shaggy Haywood wrote:
Groovy hepcat jacob navia was jivin'

.... snip ...

In most implementations a NULL dereference
traps, and the error is pinpointed exactly
where it arises. With bogus values in a
pointer there is some chance that the pointer
destroys other data structures. Using NULL
there is none. The integrity of the program itself
is not destroyed.


And what is the point of all this tripe?


I originally thought he was making a joke and didn't bother reading
it. From the portion you quoted it appears he was actually
serious! He is proposing YANCIC [1] in the wrong forum.

[1] Yet another Navian change in C.

--
"I support the Red Sox and any team that beats the Yankees"

"Any baby snookums can be a Yankee fan, it takes real moral
fiber to be a Red Sox fan"
Nov 14 '05 #15

P: n/a
jacob navia <ja***@jacob.remcomp.fr> wrote in message news:<41**********************@news.wanadoo.fr>...
-- snip --
Most locals space is small anyway.

The problems arising from reading write-only
memory would be restricted to hard traps in
the program, very easy to pinpoint to a
specific line of code.


Most local space is small, but do you know how many times it is
recreated. In something I wrote a tokenising function can be called
of the order of 1 billion times. Granted, this is not the best
design, but at present it works tolerably quickly. If this tiny
function also had to wipe the local memory it uses it might well make
the whole application much slower.

Bits of code that depend on recursion could also suffer.

Extensions like those you mention might be useful in this area though.
Nov 14 '05 #16

P: n/a
In <41**********************@news.wanadoo.fr> jacob navia <ja***@jacob.remcomp.fr> writes:
In C, we have read-only memory (const), read/write memory
(normal data), and write only memory.

Let's look at the third one in more detail.

Write only memory is a piece of RAM that can only
be written to, since its contents are undefined.
But, once you have written something to it, it is no longer write only,
according to your own definition.

Real write only "memory" has the property that it cannot be read back
and produce the value that was previously written to it. The memory
mapped registers of certain I/O devices behave like this. The same
memory location can be both read and written, but with different
semantics (e.g. it is convenient to map the Tx and Rx registers of
an UART at the same address).
The program is allocating a new piece of data, and
the previous contents aren't relevant. This memory
is generated by malloc and friends, or allocated
statically by the compiler by making the processor
increase the stack area at the entry of the function.

When you read from write only memory (you use an
uninitialized variable) the behavior is undefined,
i.e. it is declared a big mistake.

It is big because the consequences are random. When
a value is read from that memory locations, its contents
are random. We know that if we have rebooted maybe the
OS has just cleaned up and this memory is not quite
random, it is mostly zero. If the machine is running
since a while however, the contents are probably
whatever data was written to that address before, in
another program.

The symptoms are very vague. Programs that run at the
start stop working, a program that has just run crashes,
symptoms that *could* be related to this program or not.

Confusing symptoms.

This confusion is because of the random nature of the
data being introduced in the program.

The great remedy of course, is to have default values
for all local variables and set them at the start. This
doesn't eliminate all bugs, but at least
eliminates those of reading from write only memory.


You are naive. Most compilers can detect most attempts to read from
uninitialised memory, when automatically allocated. Statically allocated
memory is always initialised and, for dynamically allocated memory, there
is always calloc.

The *hard* cases are detecting attempts to read values that have become
indeterminate during the program execution. Examples:

#include <stdlib.h>

int *foo(void)
{
int i;
return &i;
}

int main()
{
char *p = malloc(10);
int *q = foo();

free(p);
p[5] = 'a';
*q = 42;
}

The value of p becomes indeterminate after the free call and any attempt
to use it (except for examining its representation on a byte by byte
basis) results in undefined behaviour.

The pointer value returned by foo() is already indeterminate when
assigned to q, because the pointed-to object no longer exists. Writing
through q can have very *interesting* effects, indeed.

These *are* a source of very subtle bugs, indeed. If you want to try
your hand at doing something useful, have your compiler detect *all*
the pointers that become indeterminate when an object no longer exists
(through one or another of the two mechanisms illustrated above)
and nullify their values. This way, any attempt to read or write
through them could reliably crash the program.

Good luck,
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
Nov 14 '05 #17

P: n/a
On 19 Oct 2004 20:09:26 GMT, Da*****@cern.ch (Dan Pop) wrote:
In <41**********************@news.wanadoo.fr> jacob navia <ja***@jacob.remcomp.fr> writes:

<snip>
The great remedy of course, is to have default values
for all local variables and set them at the start. This
doesn't eliminate all bugs, but at least
eliminates those of reading from write only memory.


You are naive. Most compilers can detect most attempts to read from
uninitialised memory, when automatically allocated. Statically allocated
memory is always initialised and, for dynamically allocated memory, there
is always calloc.

I assume you mean _simple, scalar, unaliased_ automatic variables.

Which may well be "most" cases, if only because use of such variables
is the most common case of object use.

But there are many uses of uninitialized automatic memory which cannot
(practically, or at all) be detected at compile time:

{
int a, b = 0, *p;
p = some computation that might be &a or &b
*p = 1;
a; // initialized?
}

{
int x[10], i;
for( i = 0; i < 5; i++ ) x[i] = i;
i = some computation that might be < 5 or >= 5
x[i]; // initialized?
}

etc. I do sometimes, if there is any significant complexity to the
logic, default-fill such variables so at least my bugs are Bohr-ing.

- David.Thompson1 at worldnet.att.net
Nov 14 '05 #18

P: n/a
In <mm********************************@4ax.com> Dave Thompson <da*************@worldnet.att.net> writes:
On 19 Oct 2004 20:09:26 GMT, Da*****@cern.ch (Dan Pop) wrote:
In <41**********************@news.wanadoo.fr> jacob navia <ja***@jacob.remcomp.fr> writes:

<snip>
>The great remedy of course, is to have default values
>for all local variables and set them at the start. This
>doesn't eliminate all bugs, but at least
>eliminates those of reading from write only memory.


You are naive. Most compilers can detect most attempts to read from
uninitialised memory, when automatically allocated. Statically allocated
memory is always initialised and, for dynamically allocated memory, there
is always calloc.

I assume you mean _simple, scalar, unaliased_ automatic variables.

Which may well be "most" cases, if only because use of such variables
is the most common case of object use.


It's also most cases because these are the variables that are left
uninitialised most of the time. People are a lot more careful to
initialise their aggregates than their scalars.

Most of the uncatchable examples are contrived, designed on purpose rather
than arising from real code.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
Nov 14 '05 #19

This discussion thread is closed

Replies have been disabled for this discussion.