Another question related to pointers.

[anonymous]

Dear All,

From my understanding of pointers, a pointer should not be able to

access a memory location until that memory has been allocated either by
assiging the address of a variable
or either through malloc i.e.

ptr = &somevariable;

or

ptr = malloc ( sizeof ( data ) );

However, what I discovered with the following program has made me a bit
uneasy.
Not only can I read the memory pointed to by pointers that still have
not been allocated any
memory, I can write as well.

Can somebody please explain, why pointers p1 and p2 can read from and
read to memory
that they have not been allocated?

Thanks in advance for all your help.

#include <stdio.h>
int main ( void )
{
int *ptr1, *ptr2;

/* Get read access to the memory pointed to by p1 and p2 */
printf ( "*p1 = %d\n", *p1 );
printf ( "*p2 = %d\n", *p2 );

/* Write to the memory pointed to by p1 and p2 */

*p1 = 1;
*p2 = 2;

/* Confirm the write operation */
printf ( "*p1 = %d\n", *p1 );
printf ( "*p2 = %d\n", *p2 );

return 0;
}

[olaf_giezenaar]

Hello
This is luck that it works.

The declared pointers have a value, C doesn't zero memory on
declaration!!!

What actual is happening is that you are reading/writeing on a random
place in memory.

the behaivior of this is undefined.

All things can happen.

Greetings Olaf

[usenet]

anonymous <ca******@yahoo.com> wrote:

Dear All,

From my understanding of pointers, a pointer should not be able to

access a memory location until that memory has been allocated either
by assiging the address of a variable or either through malloc i.e.

ptr = &somevariable;

or

ptr = malloc ( sizeof ( data ) );

However, what I discovered with the following program has made me a
bit uneasy. Not only can I read the memory pointed to by pointers
that still have not been allocated any memory, I can write as well.

Can somebody please explain, why pointers p1 and p2 can read from and
read to memory that they have not been allocated?

You have not yet allocated any storage, but pointers always point
*somewhere*. Since you declare the pointers p1 and p2 as automatic
variables (on the stack), their value (the memory location they are
pointing to, not their *content*) is uninitialized, and just contain
the value that happened to be in that spot of memory.

What you are doing by accessing the pointers is just reading and - even
worse, writing - to *some* memory, but you don't know where. Blindfold
yourself, take a gun, turn around 20 times and shoot. You might hit
nothing at all, you might hit the ground, or you might hit the gastank
you are standing next to. Just don't do it.

--
:wq
^X^Cy^K^X^C^C^C^C

[anonymous]

ol************@hotmail.com wrote:

Hello
This is luck that it works.

The declared pointers have a value, C doesn't zero memory on
declaration!!!

What actual is happening is that you are reading/writeing on a random
place in memory.

the behaivior of this is undefined.

All things can happen.

Greetings Olaf

That is what I also think i.e. the pointers are pointing to *any*
memory as per garbage
values stored in p1 and p2 and, in turn, garbage value in the pointed
memory is being
accessed. But just try this program below. According to above
hypothesis, this should
work again, but it does not. You get a segmentation fault even on a
read operation of an
arbitrary memory location. Why cannot I access this memory now if I
could access the
memory pointed to by *garbage* address in p1. In fact, I tried with
various input values
of address and it would not read or write to any other memory location
that I could think of. May be try generating all possible addresses and
try to read and write all memory
locations right from 0000 0000 to ffff ffff and then figure out any
result.
#include <stdio.h>
int main ( void )
{
int *p1, address;

/* You can do read and write with the garbage address in p1 */
printf ( " *p1 = %d\n", *p1 );
*p1 = 0x12345678;

/* Now get some address from the user */
scanf ( "%x", &address );

/* Initialize your pointer with this address */
p1 = ( int * ) address;

/* Try reading from memory pointed to by the address */
/* You get a segmentation fault this point onwards */

printf ( " *p1 = %d\n", *p1 );

/* Try writing to memory pointed to be the address */
*p1 = 0x12345678;

/* Confirm the write operation */
printf ( " *p1 = %d\n", *p1 );

return 0;
}

[Eric Sosman]

anonymous wrote:

[...]
However, what I discovered with the following program has made me a bit
uneasy. [...]

I'd be uneasy, too, if the compiler actually accepted
the program without issuing a diagnostic as the Standard
requires.

When will people learn to post the actual code whose
behavior mystifies them, instead of typing in something
with a sketchy resemblance to that code? If a program's
behavior baffles you, you are the LEAST qualified to make
a paraphrase that preserves all the important points --
you don't know what's going on, so you don't know what
matters and what doesn't, what to leave in and what to
remove. Solution: Take out nothing, add nothing, and
post the actual code. Period.

In this particular case it's easy to work backwards
and see what you probably meant, but please Please PLEASE
don't make a habit of this nonsense! Next time you may not
be so lucky, and the combined Great Minds of c.l.c. will
happily debug the errors you introduced in the process of
making your paraphrase, leaving undiagnosed the actual error
that's bothering you but that vanished in translation.

Harrumph. Consider your wrist officially slapped.

--
Eric Sosman
es*****@acm-dot-org.invalid

[Keith Thompson]

"anonymous" <ca******@yahoo.com> writes:

From my understanding of pointers, a pointer should not be able to
access a memory location until that memory has been allocated either
by assiging the address of a variable or either through malloc i.e.

ptr = &somevariable;

or

ptr = malloc ( sizeof ( data ) );

However, what I discovered with the following program has made me a
bit uneasy. Not only can I read the memory pointed to by pointers
that still have not been allocated any memory, I can write as well.

You *can*, but you may not.

--
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.

[slebetman]

anonymous wrote:

Dear All,

From my understanding of pointers, a pointer SHOULD NOT BE ABLE to
access a memory location until that memory has been allocated either by
assiging the address of a variable or either through malloc i.e.
(note: emphasis mine)

Actually this is not true. A pointer SHOULD NOT BE USED to access
memory location until that memory has been allocated. C, being a system
programming language SHOULD BE ABLE to do this though. C was intended
to expose as much of the hardware as possible so that one can write an
OS in it.

If C can't do this how are you supposed to write a malloc function in C
(for example the gnu malloc)? Another example use of an unallocated
pointer is in embedded systems where you often don't have an OS
running. In such cases it is common to access memory mapped hardware by
simply pointing to it. Say for example you have an I/O card at memory
location 0xffff10. You can simply access it by declaring int * io_card
= 0xffff10. Of course, on a memory protected OS this doesn't work and
segfaults. But C makes no assumption about the OS which is good since
sometimes one needs to use it where an OS is not running.

[Jack Klein]

On 5 Jan 2006 03:14:07 -0800, "anonymous" <ca******@yahoo.com> wrote
in comp.lang.c:

ol************@hotmail.com wrote:

Hello
This is luck that it works.

The declared pointers have a value, C doesn't zero memory on
declaration!!!

What actual is happening is that you are reading/writeing on a random
place in memory.

the behaivior of this is undefined.

All things can happen.

Greetings Olaf

That is what I also think i.e. the pointers are pointing to *any*
memory as per garbage
values stored in p1 and p2 and, in turn, garbage value in the pointed
memory is being
accessed. But just try this program below. According to above
hypothesis, this should
work again, but it does not. You get a segmentation fault even on a
read operation of an
arbitrary memory location. Why cannot I access this memory now if I
could access the
memory pointed to by *garbage* address in p1. In fact, I tried with
various input values
of address and it would not read or write to any other memory location
that I could think of. May be try generating all possible addresses and
try to read and write all memory
locations right from 0000 0000 to ffff ffff and then figure out any
result.
#include <stdio.h>
int main ( void )
{
int *p1, address;

/* You can do read and write with the garbage address in p1 */
printf ( " *p1 = %d\n", *p1 );
*p1 = 0x12345678;

/* Now get some address from the user */
scanf ( "%x", &address );

/* Initialize your pointer with this address */
p1 = ( int * ) address;

/* Try reading from memory pointed to by the address */
/* You get a segmentation fault this point onwards */

printf ( " *p1 = %d\n", *p1 );

/* Try writing to memory pointed to be the address */
*p1 = 0x12345678;

/* Confirm the write operation */
printf ( " *p1 = %d\n", *p1 );

return 0;
}

"Undefined behavior" has a specific meaning in C, as defined in the C
standard. Once a program generates undefined behavior, the C standard
no longer places any requirements on it. No requirement to do what
you want, no requirement to do something you did not want, no
requirement to crash the program. No requirement to do the same thing
twice. No requirements at all.

Once you know that your program causes undefined behavior, as you have
been told, than the reasons why any particular result happens or does
not happen is not a language issue. There is no C answer.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[anonymous]

Eric Sosman wrote:

anonymous wrote:

[...]
However, what I discovered with the following program has made me a bit
uneasy. [...]
I'd be uneasy, too, if the compiler actually accepted
the program without issuing a diagnostic as the Standard
requires.

When will people learn to post the actual code whose
behavior mystifies them, instead of typing in something
with a sketchy resemblance to that code? If a program's
behavior baffles you, you are the LEAST qualified to make
a paraphrase that preserves all the important points --
you don't know what's going on, so you don't know what
matters and what doesn't, what to leave in and what to
remove. Solution: Take out nothing, add nothing, and
post the actual code. Period.

In this particular case it's easy to work backwards
and see what you probably meant, but please Please PLEASE
don't make a habit of this nonsense! Next time you may not
be so lucky, and the combined Great Minds of c.l.c. will
happily debug the errors you introduced in the process of
making your paraphrase, leaving undiagnosed the actual error
that's bothering you but that vanished in translation.

I agree with all of the above that you have written. BUT, how do you
ASSUME that I have not posted the *actual code*. Though it would
be OT to describe all this, but the fact is I was just refreshing my
knowledge reading a book and tried the above program on a
thought to test pointers. Nothing more. There is no other *actual*
code. So, who should LEARN in this case, what to post and what
not to post?

Harrumph. Consider your wrist officially slapped.
Though what I have described above is fact of matter. You may
take this as an official reply :-)

Thanks for your help.

--
Eric Sosman
es*****@acm-dot-org.invalid

[Keith Thompson]

"anonymous" <ca******@yahoo.com> writes:

Eric Sosman wrote:

anonymous wrote:

> [...]
> However, what I discovered with the following program has made me a bit
> uneasy. [...]

I'd be uneasy, too, if the compiler actually accepted
the program without issuing a diagnostic as the Standard
requires.

When will people learn to post the actual code whose
behavior mystifies them, instead of typing in something
with a sketchy resemblance to that code? If a program's
behavior baffles you, you are the LEAST qualified to make
a paraphrase that preserves all the important points --
you don't know what's going on, so you don't know what
matters and what doesn't, what to leave in and what to
remove. Solution: Take out nothing, add nothing, and
post the actual code. Period.

In this particular case it's easy to work backwards
and see what you probably meant, but please Please PLEASE
don't make a habit of this nonsense! Next time you may not
be so lucky, and the combined Great Minds of c.l.c. will
happily debug the errors you introduced in the process of
making your paraphrase, leaving undiagnosed the actual error
that's bothering you but that vanished in translation.

I agree with all of the above that you have written. BUT, how do you
ASSUME that I have not posted the *actual code*. Though it would
be OT to describe all this, but the fact is I was just refreshing my
knowledge reading a book and tried the above program on a
thought to test pointers. Nothing more. There is no other *actual*
code. So, who should LEARN in this case, what to post and what
not to post?

Your question was:

] Can somebody please explain, why pointers p1 and p2 can read from
] and read to memory that they have not been allocated?

And here's the "actual code" that you posted:

#include <stdio.h>
int main ( void )
{
int *ptr1, *ptr2;

/* Get read access to the memory pointed to by p1 and p2 */
printf ( "*p1 = %d\n", *p1 );
printf ( "*p2 = %d\n", *p2 );

/* Write to the memory pointed to by p1 and p2 */

*p1 = 1;
*p2 = 2;

/* Confirm the write operation */
printf ( "*p1 = %d\n", *p1 );
printf ( "*p2 = %d\n", *p2 );

return 0;
}

You declare two variables called ptr1 and ptr2. You then refer to two
variables called p1 and p2, which were not declared anywhere. Your
question makes it clear that you were able to compile the program, and
you were wondering about its run-time behavior. The code that you
posted could not possibly have compiled.

That's how we know you didn't post the actual code. Or am I missing
something?

--
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.

[slebetman]

anonymous wrote:

Dear All,

From my understanding of pointers, a pointer SHOULD NOT BE ABLE to
access a memory location until that memory has been allocated either by
assiging the address of a variable or either through malloc i.e.
(note: emphasis mine)

Actually this is not true. A pointer SHOULD NOT BE USED to access
memory location until that memory has been allocated. C, being a system
programming language SHOULD BE ABLE to do this though. C was intended
to expose as much of the hardware as possible so that one can write an
OS in it.

If C can't do this how are you supposed to write a malloc function in C
(for example the gnu malloc)? Another example use of an unallocated
pointer is in embedded systems where you often don't have an OS
running. In such cases it is common to access memory mapped hardware by
simply pointing to it. Say for example you have an I/O card at memory
location 0xffff10. You can simply access it by declaring int * io_card
= 0xffff10. Of course, on a memory protected OS this doesn't work and
segfaults. But C makes no assumption about the OS which is good since
sometimes one needs to use it where an OS is not running.

[slebetman]

anonymous wrote:

Dear All,

From my understanding of pointers, a pointer SHOULD NOT BE ABLE to
access a memory location until that memory has been allocated either by
assiging the address of a variable or either through malloc i.e.
(note: emphasis mine)

Actually this is not true. A pointer SHOULD NOT BE USED to access
memory location until that memory has been allocated. C, being a system
programming language SHOULD BE ABLE to do this though. C was intended
to expose as much of the hardware as possible so that one can write an
OS in it.

If C can't do this how are you supposed to write a malloc function in C
(for example the gnu malloc)? Another example use of an unallocated
pointer is in embedded systems where you often don't have an OS
running. In such cases it is common to access memory mapped hardware by
simply pointing to it. Say for example you have an I/O card at memory
location 0xffff10. You can simply access it by declaring int * io_card
= 0xffff10. Of course, on a memory protected OS this doesn't work and
segfaults. But C makes no assumption about the OS which is good since
sometimes one needs to use it where an OS is not running.

[suresh]

sl*******@yahoo.com wrote:

anonymous wrote:

Dear All,

From my understanding of pointers, a pointer SHOULD NOT BE ABLE to
access a memory location until that memory has been allocated either by
assiging the address of a variable or either through malloc i.e.
(note: emphasis mine)

Actually this is not true. A pointer SHOULD NOT BE USED to access
memory location until that memory has been allocated. C, being a system
programming language SHOULD BE ABLE to do this though. C was intended
to expose as much of the hardware as possible so that one can write an
OS in it.

If C can't do this how are you supposed to write a malloc function in C
(for example the gnu malloc)?

Well, I don't have to implement malloc because it is provided by
standard C. (I assume the standard C libraries provided need not be
implemented in standard C)

-suresh

[Richard Heathfield]

anonymous said:

BUT, how do you ASSUME that I have not posted the *actual code*.
Because you implied that you had run the code (otherwise how could you
observe its behaviour?), and yet the code contained errors that would have
prevented its compilation.

So, in short, you lied.
Though it would
be OT to describe all this, but the fact is I was just refreshing my
knowledge reading a book and tried the above program on a
thought to test pointers.

How can you try it without running it?
How can you run it without compiling it?
How can you compile it without getting rid of the errors in it?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[slebetman]

suresh wrote:

sl*******@yahoo.com wrote:

anonymous wrote:

Dear All,

From my understanding of pointers, a pointer SHOULD NOT BE ABLE to
access a memory location until that memory has been allocated either by
assiging the address of a variable or either through malloc i.e.

<snip>
If C can't do this how are you supposed to write a malloc function in C
(for example the gnu malloc)?

Well, I don't have to implement malloc because it is provided by
standard C. (I assume the standard C libraries provided need not be
implemented in standard C)

You don't HAVE to implement malloc. But it is nice to have the power to
implement your own malloc if needed. Again my example is the gnu
malloc, see http://www.faqs.org/docs/securing/gnumaloc.html for why you
may want this.

[Chuck F.]

suresh wrote:

sl*******@yahoo.com wrote:

.... snip ...

Actually this is not true. A pointer SHOULD NOT BE USED to
access memory location until that memory has been allocated.
C, being a system programming language SHOULD BE ABLE to do
this though. C was intended to expose as much of the hardware
as possible so that one can write an OS in it.

If C can't do this how are you supposed to write a malloc
function in C (for example the gnu malloc)?

Well, I don't have to implement malloc because it is provided by
standard C. (I assume the standard C libraries provided need
not be implemented in standard C)

You need not bend the standard very much to write a malloc. In the
case of my nmalloc for DJGPP (ref below) I think all that is needed
is the assumption that pointer to/from int casts are meaningful,
that alignment can be measured against those casts, and that memory
can be secured from the OS with the (non-standard) sbrk call.

<http://cbfalconer.home.att.net/download/nmalloc.zip>

--
Some informative links:
news:news.announce.newusers
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html

[anonymous]

Richard Heathfield wrote:

anonymous said:

BUT, how do you ASSUME that I have not posted the *actual code*.
Because you implied that you had run the code (otherwise how could you
observe its behaviour?), and yet the code contained errors that would have
prevented its compilation.

You are absolutely alright and I have explained in the other post.
So, in short, you lied.
I regret the mistake, but don't you think that "lie" is a bit harsh
word as used here?

Though it would
be OT to describe all this, but the fact is I was just refreshing my
knowledge reading a book and tried the above program on a
thought to test pointers.

How can you try it without running it?
How can you run it without compiling it?
How can you compile it without getting rid of the errors in it?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Markus Becker]

anonymous <ca******@yahoo.com> schrieb:

int main ( void )
{
int *ptr1, *ptr2;

/* Write to the memory pointed to by p1 and p2 */

*p1 = 1;
*p2 = 2;

Hey, don't you ever do that again! One of these pointers actually
pointed to my bank account and corrupted it.

;-)

Markus

[Kenny McCormack]

In article <11**********************@g14g2000cwa.googlegroups .com>,
sl*******@yahoo.com <sl*******@gmail.com> wrote:

anonymous wrote:

Dear All,

From my understanding of pointers, a pointer SHOULD NOT BE ABLE to
access a memory location until that memory has been allocated either by
assiging the address of a variable or either through malloc i.e.
(note: emphasis mine)

Actually this is not true. A pointer SHOULD NOT BE USED to access
memory location until that memory has been allocated. C, being a system
programming language SHOULD BE ABLE to do this though. C was intended
to expose as much of the hardware as possible so that one can write an
OS in it.

According to the "experts" in this ng, you *can't* write an OS in C.

(This is taking the religious dogma as expressed by some that anything that
isn't "standard C" isn't "C". Yes, as hard as it is to believe, I've seen
exactly that thought expressed here in just those words.)

[Herbert Rosenau]

On Thu, 5 Jan 2006 10:32:31 UTC, "anonymous" <ca******@yahoo.com>
wrote:

Dear All,

From my understanding of pointers, a pointer should not be able to access a memory location until that memory has been allocated either by
assiging the address of a variable
or either through malloc i.e.

ptr = &somevariable;

or

ptr = malloc ( sizeof ( data ) );

However, what I discovered with the following program has made me a bit
uneasy.
Not only can I read the memory pointed to by pointers that still have
not been allocated any
memory, I can write as well.

Can somebody please explain, why pointers p1 and p2 can read from and
read to memory
that they have not been allocated?

Thanks in advance for all your help.

#include <stdio.h>
int main ( void )
{
int *ptr1, *ptr2;

/* Get read access to the memory pointed to by p1 and p2 */
printf ( "*p1 = %d\n", *p1 );
printf ( "*p2 = %d\n", *p2 );

undefined behavior

/* Write to the memory pointed to by p1 and p2 */

*p1 = 1;
*p2 = 2;
again undefined behavior
/* Confirm the write operation */
printf ( "*p1 = %d\n", *p1 );
printf ( "*p2 = %d\n", *p2 );
undefined behavior

return 0;
}

undefined behavior behaves undefined in any possible case. That
includes that it may or may not work as expected either sometimes or
ever or never maybe depending on sunshine or wether, it can produce
maximum damage after showing maximum harmless during debug.....

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

[Keith Thompson]

"anonymous" <ca******@yahoo.com> writes:

Richard Heathfield wrote:

anonymous said:

> BUT, how do you ASSUME that I have not posted the *actual code*.

Because you implied that you had run the code (otherwise how could you
observe its behaviour?), and yet the code contained errors that would have
prevented its compilation.

You are absolutely alright and I have explained in the other post.

I don't see that other post you referred to, either on my server or on
groups.google.com. (That doesn't imply that you didn't post it, only
that it didn't get through.)

It's not a big deal; if you say it was an honest mistake, I'll take
your word for it.

--
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.

[Herbert Rosenau]

On Fri, 6 Jan 2006 16:08:32 UTC, ga*****@yin.interaccess.com (Kenny
McCormack) wrote:

According to the "experts" in this ng, you *can't* write an OS in C.

(This is taking the religious dogma as expressed by some that anything that
isn't "standard C" isn't "C".

You're absolutely wrong. I have written an complete OS using 100% ANSI
C whereas 2% of all were 100% assembly for performance and direct
hardware access. But at least not a single C statement was not ANSI
compilant.

Our quality management had required to use ANSI compilance AND coding
C wherever halfways possible. The 2% NON C was absolutely needed to
get the real work done reliable to make direct hardware access C is
unable to do in any case.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

[Chuck F.]

Herbert Rosenau wrote:

ga*****@yin.interaccess.com (Kenny McCormack) wrote:

According to the "experts" in this ng, you *can't* write an OS
in C.

(This is taking the religious dogma as expressed by some that
anything that isn't "standard C" isn't "C".

You're absolutely wrong. I have written an complete OS using
100% ANSI C whereas 2% of all were 100% assembly for performance
and direct hardware access. But at least not a single C
statement was not ANSI compilant.

.... snip ...
_____________________
/| /| | F
||__|| | Please do not |
/ O O\__ | feed the |
/ \ | Trolls |
/ \ \|_____________________|
/ _ \ \ ||
/ |\____\ \ ||
/ | | | |\____/ ||
/ \|_|_|/ | _||
/ / \ |____| ||
/ | | | --|
| | | |____ --|
* _ | |_|_|_| | \-/
-- _--\ _ \ | ||
/ _ \\ | / `
/ \_ /- | | |
* ___ c_c_c_C/ \C_c_c_c____________

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>

[Kenny McCormack]

In article <wm***************************@URANUS1.DV-ROSENAU.DE>,
Herbert Rosenau <os****@pc-rosenau.de> wrote:
....

According to the "experts" in this ng, you *can't* write an OS in C.

(This is taking the religious dogma as expressed by some that anything that
isn't "standard C" isn't "C".

You're absolutely wrong. I have written an complete OS using 100% ANSI
C whereas 2% of all were 100% assembly for performance and direct
hardware access. But at least not a single C statement was not ANSI
compilant.

Thank you for making my case for me. I assume that you meant 98% ANSI C,
as in, "my OS was written in a combination of C and assembler, in an
approximate ratio of 49 to 1".

Then we can consider the matter closed.

[anonymous]

Keith Thompson wrote:

"anonymous" <ca******@yahoo.com> writes:

Eric Sosman wrote:

anonymous wrote:
> [...]
> However, what I discovered with the following program has made me a bit
> uneasy. [...]

I'd be uneasy, too, if the compiler actually accepted
the program without issuing a diagnostic as the Standard
requires.

When will people learn to post the actual code whose
behavior mystifies them, instead of typing in something
with a sketchy resemblance to that code? If a program's
behavior baffles you, you are the LEAST qualified to make
a paraphrase that preserves all the important points --
you don't know what's going on, so you don't know what
matters and what doesn't, what to leave in and what to
remove. Solution: Take out nothing, add nothing, and
post the actual code. Period.

In this particular case it's easy to work backwards
and see what you probably meant, but please Please PLEASE
don't make a habit of this nonsense! Next time you may not
be so lucky, and the combined Great Minds of c.l.c. will
happily debug the errors you introduced in the process of
making your paraphrase, leaving undiagnosed the actual error
that's bothering you but that vanished in translation.
I agree with all of the above that you have written. BUT, how do you
ASSUME that I have not posted the *actual code*. Though it would
be OT to describe all this, but the fact is I was just refreshing my
knowledge reading a book and tried the above program on a
thought to test pointers. Nothing more. There is no other *actual*
code. So, who should LEARN in this case, what to post and what
not to post?

Your question was:

] Can somebody please explain, why pointers p1 and p2 can read from
] and read to memory that they have not been allocated?

And here's the "actual code" that you posted:

#include <stdio.h>
int main ( void )
{
int *ptr1, *ptr2;

/* Get read access to the memory pointed to by p1 and p2 */
printf ( "*p1 = %d\n", *p1 );
printf ( "*p2 = %d\n", *p2 );

/* Write to the memory pointed to by p1 and p2 */

*p1 = 1;
*p2 = 2;

/* Confirm the write operation */
printf ( "*p1 = %d\n", *p1 );
printf ( "*p2 = %d\n", *p2 );

return 0;
}

You declare two variables called ptr1 and ptr2. You then refer to two
variables called p1 and p2, which were not declared anywhere. Your
question makes it clear that you were able to compile the program, and
you were wondering about its run-time behavior. The code that you
posted could not possibly have compiled.

That's how we know you didn't post the actual code. Or am I missing
something?

Oh. Now I see the point and understand what is meant by *actual code*.
Very right, the code I posted was not the same file ptr.c that I tested
on
my computer which I do not use for the Internet. I could have
probably taken the file to the other machine, but rather just typed it
instead
in my mail. Apart from the two erros, rest of the code is the same,
*otherwise*
( I think this would convince me and others as well ).

I understand posting the file gets me better help which you all
provide.

Many thanks,

A.

--
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.

[Vadivel]

According to my understanding of the program. It will give compilation
error for the pointer variable's p1 and p2, which is not declared in
the given program code.

If you considered that p1 as ptr1 and p2 as ptr2, the happening in the
Enviornment is as follows,

When we declaring a variable (either it is pointer or not pointer ) the
memory will be alloted for that variable in the memory register. While
allocating the memory the Enviornment will store some maximum or
minimum value in that corresponding alocation as a Garbage Value in
accordance to the Data Type.

So, when we refer to the variable it will interrupt the Memory Register
and fetch the value stored in it, because of this process you can able
to execute the program after correcting the variables as ptr1 and ptr2
instead of p1 and p2 respectively.

And also you should remain that the Function Printf will carry only the
memory address of the variable which is passed to it. It won't carry
the values to execute the fuction.

If any one having Controversy in my explain please mail me your
explaination to va*******@gmail.com

[Emmanuel Delahaye]

anonymous a écrit :

From my understanding of pointers, a pointer should not be able to access a memory location until that memory has been allocated

This is not the point.
either by
assiging the address of a variable
or either through malloc i.e.
This is the point. To be dereferenced, a pointer must hold the address
of a valid memory zone, unless, the behaviour is undefined. Period.
Not only can I read the memory pointed to by pointers that still have
not been allocated any
Of course, it is technically possible to invoke an Undefined Behaviour
(or shot a bullet in your foot), but it's still a bug. Don't do that.
memory, I can write as well.

Can somebody please explain, why pointers p1 and p2 can read from and
read to memory
that they have not been allocated?
A pointer is nothing but a variable. If its content is undefined, or the
address of an undefined memory zone, nasty things are going to happen.
int *ptr1, *ptr2;

/* Get read access to the memory pointed to by p1 and p2 */
printf ( "*p1 = %d\n", *p1 );

what is p1 ? You defined ptr1 ... Please compile before posting. And
don't retype, but copy & paste.

--
A+

Emmanuel Delahaye

[Emmanuel Delahaye]

anonymous a écrit :

That is what I also think i.e. the pointers are pointing to *any*
memory as per garbage
values stored in p1 and p2 and, in turn, garbage value in the pointed
memory is being
accessed.

Don't try to find any logic in an undefined behaviour. Your code is
wrong by construct, fix it and don't waste your time.

--
A+

Emmanuel Delahaye

[slebetman]

Kenny McCormack wrote:

In article <11**********************@g14g2000cwa.googlegroups .com>,
sl*******@yahoo.com <sl*******@gmail.com> wrote:

anonymous wrote:

Dear All,

From my understanding of pointers, a pointer SHOULD NOT BE ABLE to
access a memory location until that memory has been allocated either by
assiging the address of a variable or either through malloc i.e.
(note: emphasis mine)

Actually this is not true. A pointer SHOULD NOT BE USED to access
memory location until that memory has been allocated. C, being a system
programming language SHOULD BE ABLE to do this though. C was intended
to expose as much of the hardware as possible so that one can write an
OS in it.

According to the "experts" in this ng, you *can't* write an OS in C.

I know, I know. Don't feed the troll. But let me first say that writing
an OS is what C was originally designed to do.

Was the OS in question (Unix) written entirely in C? Probably not. But
was the 'core' of the OS (the kernel) written entirely in C? Yes. And
before anyone points out that it was not 'standard' C let me point out
that that 'C' was what Dennis Ritchie recognised as C (so at least it
was K&R C). Let me quote Dennis Ritchie on this:

In 1993 Dennis M. Ritchie wrote:
By early 1973, the essentials of modern C were complete. The language
and
compiler were strong enough to permit us to rewrite the Unix kernel
for the
PDP-11 in C during the summer of that year.
( taken from http://cm.bell-labs.com/cm/cs/who/dmr/chist.html )

[slebetman]

Kenny McCormack wrote:

In article <11**********************@g14g2000cwa.googlegroups .com>,
sl*******@yahoo.com <sl*******@gmail.com> wrote:

anonymous wrote:

Dear All,

From my understanding of pointers, a pointer SHOULD NOT BE ABLE to
access a memory location until that memory has been allocated either by
assiging the address of a variable or either through malloc i.e.
(note: emphasis mine)

Actually this is not true. A pointer SHOULD NOT BE USED to access
memory location until that memory has been allocated. C, being a system
programming language SHOULD BE ABLE to do this though. C was intended
to expose as much of the hardware as possible so that one can write an
OS in it.

According to the "experts" in this ng, you *can't* write an OS in C.

I know, I know. Don't feed the troll. But let me first say that writing
an OS is what C was originally designed to do.

Was the OS in question (Unix) written entirely in C? Probably not. But
was the 'core' of the OS (the kernel) written entirely in C? Yes. And
before anyone points out that it was not 'standard' C let me point out
that that 'C' was what Dennis Ritchie recognised as C (so at least it
was K&R C). Let me quote Dennis Ritchie on this:

In 1993 Dennis M. Ritchie wrote:
By early 1973, the essentials of modern C were complete. The language
and
compiler were strong enough to permit us to rewrite the Unix kernel
for the
PDP-11 in C during the summer of that year.
( taken from http://cm.bell-labs.com/cm/cs/who/dmr/chist.html )

[Richard Bos]

"sl*******@yahoo.com" <sl*******@gmail.com> wrote:

Kenny McCormack wrote:

According to the "experts" in this ng, you *can't* write an OS in C.
I know, I know. Don't feed the troll. But let me first say that writing
an OS is what C was originally designed to do.

That's not how I read that article.
Was the OS in question (Unix) written entirely in C? Probably not. But
was the 'core' of the OS (the kernel) written entirely in C? Yes. And
before anyone points out that it was not 'standard' C let me point out
that that 'C' was what Dennis Ritchie recognised as C (so at least it
was K&R C). Let me quote Dennis Ritchie on this:

In 1993 Dennis M. Ritchie wrote:
By early 1973, the essentials of modern C were complete. The language and
compiler were strong enough to permit us to rewrite the Unix kernel for the
PDP-11 in C during the summer of that year.
( taken from http://cm.bell-labs.com/cm/cs/who/dmr/chist.html )

Note: _re_write. The original Unix was not written in C. And the
original C was not written primarily to write Unix in, but to be used as
a system programming language _under_ Unix.

Richard

[slebetman]

Richard Bos wrote:

"sl*******@yahoo.com" <sl*******@gmail.com> wrote:

Kenny McCormack wrote:

According to the "experts" in this ng, you *can't* write an OS in C.

I know, I know. Don't feed the troll. But let me first say that writing
an OS is what C was originally designed to do.

That's not how I read that article.

Was the OS in question (Unix) written entirely in C? Probably not. But
was the 'core' of the OS (the kernel) written entirely in C? Yes. And
before anyone points out that it was not 'standard' C let me point out
that that 'C' was what Dennis Ritchie recognised as C (so at least it
was K&R C). Let me quote Dennis Ritchie on this:

In 1993 Dennis M. Ritchie wrote:
By early 1973, the essentials of modern C were complete. The language and
compiler were strong enough to permit us to rewrite the Unix kernel for the
PDP-11 in C during the summer of that year.
( taken from http://cm.bell-labs.com/cm/cs/who/dmr/chist.html )

Note: _re_write. The original Unix was not written in C. And the
original C was not written primarily to write Unix in, but to be used as
a system programming language _under_ Unix.

Re-write still means that it was written in C. The "originally"
released Unix (1975) was written in C. All prior versions were written
primarily for internal use (beta?) with very-very limited, if any,
outside distribution.

It is actually not true that C was merely a system programming language
_under_ Unix as Unix itself was written entirely in C. Only some device
drivers and I/O access functions were written in assembly (most of
these functions like getchar and putchar became part of C's stdlib
anyway so it can be argued that they were merely an implementation of
stdlib).

The design of (the original, K&R) C was therefore heavily influenced by
Dennis Ritchie having to write parts of Unix in his own high level
programming language. This is a good thing as they say in the business:
eating your own dog food.

[William J. Leary Jr.]

"sl*******@yahoo.com" <sl*******@gmail.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...

Re-write still means that it was written in C. The "originally"
released Unix (1975) was written in C. All prior versions
were written primarily for internal use (beta?) with very-very
limited, if any, outside distribution.

If your qualifier was "released" (and it seems to be, since you're using 1975
as a date, I assume you mean 6th edition) yes.

But originally UNIX was in B. The "rewrite in C" that I've usually heard about
was in 1973 for the 4th edition.

See http://www.english.uga.edu/hc/unixhistoryrev.html where Ken Thompson is
quoted:

----begin quote----
It was the summer of '69. In fact, my wife went on vacation to my family's
place in California.... I allocated a week each to the operating system, the
shell, the editor, and the assembler, to reproduce itself, and during the month
she was gone, it was totally rewritten in a form that looked like an operating
system, with tools that were sort of known, you know, assembler, editor, and
shell .... Yeh, essentially one person for a month.

The "language" they were writing the OS in was BCPL (Basic Combined Programming
Language)--a tool for compiler writing and systems programming. But in keeping
with their need for extreme economy, Richie wrote a "cut-down version of BCPL"
with the abbreviated name, B.
----end quote----

For the nonce, I could swear that when I heard one of these guys (Ritchie or
Thompson) speak in Boston some ten or fifteen years ago he said that the
original UNIX (or precursor to it?) was in assembler, shortly thereafter
converted to B, but I can find no on-line reference which supports this. I'm
guessing I misunderstood him.

- Bill

[slebetman]

William J. Leary Jr. wrote:

"sl*******@yahoo.com" <sl*******@gmail.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...

Re-write still means that it was written in C. The "originally"
released Unix (1975) was written in C. All prior versions
were written primarily for internal use (beta?) with very-very
limited, if any, outside distribution.

If your qualifier was "released" (and it seems to be, since you're using 1975
as a date, I assume you mean 6th edition) yes.

Actually my qualifier is not "released". It is just that my qualifier
is not "original" either. My beef is with people saying that since the
"original" Unix was not written in C then Unix was not written in C.

That logic does not follow. If Unix was written in C at some point in
its history then it is absolutely true that it "was written in C". Does
not matter which version, all that matters is that it is doable
(remember the days before Unix when people believed that an OS could
not be written in a high level language?). And all that matters is that
it is doable in C which is a reply to Kenny's statement: "According to
the "experts" in this ng, you *can't* write an OS in C".

All I'm saying is that C was designed by Dennis Ritchie at a time when
he was trying to use it to write Unix. So in a real sense, C (at least
the original K&R C) was designed so that you can write an OS in a high
level language.

This all goes back to the original poster complaining that C does not
prevent you from invoking undefined behavior like using an unallocated
pointer. My point is that it is not C's job to 'prevent' you from doing
anything. Warn you, maybe. Prevent you, no. This is because there are
times when the programmer really knows better than the compiler and
really-really want to do dangerous things which is often required when
you are writing an OS. Things like:

int *analog_input = 0x3fff20;
int buffer;
buffer = analog_input;

may be undefined by the C language but may be very well defined by the
target hardware and accompanying documentation.

[Keith Thompson]

"sl*******@yahoo.com" <sl*******@gmail.com> writes:
[...]

This all goes back to the original poster complaining that C does not
prevent you from invoking undefined behavior like using an unallocated
pointer. My point is that it is not C's job to 'prevent' you from doing
anything. Warn you, maybe. Prevent you, no. This is because there are
times when the programmer really knows better than the compiler and
really-really want to do dangerous things which is often required when
you are writing an OS. Things like:

int *analog_input = 0x3fff20;
int buffer;
buffer = analog_input;

may be undefined by the C language but may be very well defined by the
target hardware and accompanying documentation.

That code is illegal in modern C, though it was probably ok in the
ancient version of C that was first used to implement Unix. There are
no *implicit* conversions between integers and pointers (other than
the special case of a null pointer constant). And I suspect the last
assignment was meant to dereference the pointer.

In modern C, this would be something like:

int *analog_input = (int*)0x3fff20;
int buffer;
buffer = *analog_input;

You have to be a little more explicit about it, but it still nicely
illustrates the point. The code is highly non-portable, but sometimes
that kind of thing is necessary and appropriate.

I do tend to think that the really dangerous things in C look too much
like the perfectly safe things. In this case, though, the cast should
raise a red flag (most casts are either unnecessary or a sign of
non-portable code). (I've worked in other languages that are far safe
than C by default, but that allow you to get as close to the metal as
you need to if you ask nicely.)

--
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.

[Keith Thompson]

Keith Thompson <ks***@mib.org> writes:

"sl*******@yahoo.com" <sl*******@gmail.com> writes:
[...]

int *analog_input = 0x3fff20;
int buffer;
buffer = analog_input;

may be undefined by the C language but may be very well defined by the
target hardware and accompanying documentation.

[...]
In modern C, this would be something like:

int *analog_input = (int*)0x3fff20;
int buffer;
buffer = *analog_input;

The first line should probably be

volatile int *analog_input = (int*)0x3fff20;

--
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.

[slebetman]

Keith Thompson wrote:

"sl*******@yahoo.com" <sl*******@gmail.com> writes:
[...]

This all goes back to the original poster complaining that C does not
prevent you from invoking undefined behavior like using an unallocated
pointer. My point is that it is not C's job to 'prevent' you from doing
anything. Warn you, maybe. Prevent you, no. This is because there are
times when the programmer really knows better than the compiler and
really-really want to do dangerous things which is often required when
you are writing an OS. Things like:

int *analog_input = 0x3fff20;
int buffer;
buffer = analog_input;

may be undefined by the C language but may be very well defined by the
target hardware and accompanying documentation.

That code is illegal in modern C, though it was probably ok in the
ancient version of C that was first used to implement Unix. There are
no *implicit* conversions between integers and pointers (other than
the special case of a null pointer constant). And I suspect the last
assignment was meant to dereference the pointer.

In modern C, this would be something like:

int *analog_input = (int*)0x3fff20;
int buffer;
buffer = *analog_input;

Ah yes, that's what I meant. Sorry for the 'bug'.

[Dave Thompson]

On 11 Jan 2006 07:16:28 -0800, "sl*******@yahoo.com"
<sl*******@gmail.com> wrote:

Richard Bos wrote:

"sl*******@yahoo.com" <sl*******@gmail.com> wrote:

( taken from http://cm.bell-labs.com/cm/cs/who/dmr/chist.html )
Note: _re_write. The original Unix was not written in C. And the
original C was not written primarily to write Unix in, but to be used as
a system programming language _under_ Unix.

Re-write still means that it was written in C. The "originally"
released Unix (1975) was written in C. All prior versions were written
primarily for internal use (beta?) with very-very limited, if any,
outside distribution.

It is actually not true that C was merely a system programming language
_under_ Unix as Unix itself was written entirely in C. Only some device
drivers and I/O access functions were written in assembly (most of
these functions like getchar and putchar became part of C's stdlib
anyway so it can be argued that they were merely an implementation of
stdlib).

At least by 6ed I don't believe any drivers were in assembler; they
certainly didn't need to be on the PDP-11, and the ones I looked at
weren't. I didn't go through everything thoroughly but the only
assembler I remember was in system boot (and dump), first-level
interrupt handling which on the -11 includes exceptions and syscall,
trivial wrappings of inter-space access like MT/FPD, and process
switch. (The scheduler _logic_ was in C, including the (in?)famous
comment "you are not expected to understand this", but the actual
switch decided by that logic could not be.)

getchar and putchar were not (AFAIK never) in the kernel. The syscall
interface for everything was read() and write(); for character devices
(drivers) these went directly to the driver (via cdevsw) instead of
going through the block buffer/cache level first.

and 11 Jan 2006 19:41:03 -0800, "sl*******@yahoo.com"
<sl*******@gmail.com> wrote:
That logic does not follow. If Unix was written in C at some point in
its history then it is absolutely true that it "was written in C". Does
not matter which version, all that matters is that it is doable
(remember the days before Unix when people believed that an OS could
not be written in a high level language?). <snip>

That was already known (Multics and B6700 at least). What Unix/C
proved was that it could be done for a pretty minimalist design, on a
(then) small/cheap machine, and still be quite useful.

- David.Thompson1 at worldnet.att.net

[anonymous]

Dave Thompson wrote:

On 11 Jan 2006 07:16:28 -0800, "sl*******@yahoo.com"
<sl*******@gmail.com> wrote:

Richard Bos wrote:

"sl*******@yahoo.com" <sl*******@gmail.com> wrote: ( taken from http://cm.bell-labs.com/cm/cs/who/dmr/chist.html )

Note: _re_write. The original Unix was not written in C. And the
original C was not written primarily to write Unix in, but to be used as
a system programming language _under_ Unix.

Re-write still means that it was written in C. The "originally"
released Unix (1975) was written in C. All prior versions were written
primarily for internal use (beta?) with very-very limited, if any,
outside distribution.

It is actually not true that C was merely a system programming language
_under_ Unix as Unix itself was written entirely in C. Only some device
drivers and I/O access functions were written in assembly (most of
these functions like getchar and putchar became part of C's stdlib
anyway so it can be argued that they were merely an implementation of
stdlib).

At least by 6ed I don't believe any drivers were in assembler; they
certainly didn't need to be on the PDP-11, and the ones I looked at
weren't. I didn't go through everything thoroughly but the only
assembler I remember was in system boot (and dump), first-level
interrupt handling which on the -11 includes exceptions and syscall,
trivial wrappings of inter-space access like MT/FPD, and process
switch. (The scheduler _logic_ was in C, including the (in?)famous
comment "you are not expected to understand this", but the actual
switch decided by that logic could not be.)

getchar and putchar were not (AFAIK never) in the kernel. The syscall
interface for everything was read() and write(); for character devices
(drivers) these went directly to the driver (via cdevsw) instead of
going through the block buffer/cache level first.

and 11 Jan 2006 19:41:03 -0800, "sl*******@yahoo.com"
<sl*******@gmail.com> wrote:

That logic does not follow. If Unix was written in C at some point in
its history then it is absolutely true that it "was written in C". Does
not matter which version, all that matters is that it is doable
(remember the days before Unix when people believed that an OS could
not be written in a high level language?). <snip>

That was already known (Multics and B6700 at least). What Unix/C
proved was that it could be done for a pretty minimalist design, on a
(then) small/cheap machine, and still be quite useful.

- David.Thompson1 at worldnet.att.net

Many thanks all of you for providing such a detailed explanation anb
*extra* knowledge
for this pointer problem.

Thanks again.

[Jordan Abel]

On 2006-01-16, Dave Thompson <da*************@worldnet.att.net> wrote:

At least by 6ed I don't believe any drivers were in assembler; they
certainly didn't need to be on the PDP-11, and the ones I looked at
weren't. I didn't go through everything thoroughly but the only
assembler I remember was in system boot (and dump), first-level
interrupt handling which on the -11 includes exceptions and syscall,
trivial wrappings of inter-space access like MT/FPD, and process
switch. (The scheduler _logic_ was in C, including the (in?)famous
comment "you are not expected to understand this", but the actual
switch decided by that logic could not be.)

Of course, the code covered by that comment was (based on my reading of
DMR's later explanation of it) ridiculously unportable: relying on an
inappropriate amount of knowledge of compiler internals, specifically,
how the code generated for context-save and return looked in assembler.

http://cm.bell-labs.com/cm/cs/who/dmr/odd.html