what is at 0 address in a program?

[ypjofficial]

Hello All,
While readling the C and C++ literature i came to know that the OS
allocates separate protected memory space for each running program and
the program do not interfare into one another's address space.
Also the address space allocated for each program is totally relative.

Now i want to know that from what address value does the stack starts
and the heap actually start?

What is at address 0(first address) in a program?

In other words,why the variables defined in the program have their
address as 1,2,3...( of course in hexadecimal)?
The address values are always like 0x00012ffc7 and likes..

Regards,
Yogesh Joshi

[Kenny McCormack]

In article <11**********************@z14g2000cwz.googlegroups .com>,
<yp*********@indiatimes.com> wrote:

Hello All,
While readling the C and C++ literature i came to know that the OS
allocates separate protected memory space for each running program and
the program do not interfare into one another's address space.
Also the address space allocated for each program is totally relative.

Now i want to know that from what address value does the stack starts
and the heap actually start?

"Smashing the Stack" for fun & profit, are we?

[Alf P. Steinbach]

* yp*********@indiatimes.com:

Hello All,
While readling the C and C++ literature i came to know that the OS
allocates separate protected memory space for each running program and
the program do not interfare into one another's address space.
Also the address space allocated for each program is totally relative.

Now i want to know that from what address value does the stack starts
That depends on just about everything, including the phase of the moon. You
can obtain that address via assembly language. Or you can obtain an address
that is quite near to it by something as simple as

int main()
{
int a;
std::cout << &a << std::endl;
}

and the heap actually start?
There is not necessarily just one heap.

What is at address 0(first address) in a program?
Usually that is the same as pointer value 0, which means that usually (except
for embedded systems programming), on modern computers, trying to access the
contents of that address will result in some kind of exception or trap.
In other words,why the variables defined in the program have their
address as 1,2,3...( of course in hexadecimal)?
The address values are always like 0x00012ffc7 and likes..

What system do you think you're perceiving?

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[John Harrison]

yp*********@indiatimes.com wrote:

Hello All,
While readling the C and C++ literature i came to know that the OS
allocates separate protected memory space for each running program and
the program do not interfare into one another's address space.
Also the address space allocated for each program is totally relative.
The above might be true, but it has nothing at all to do with C or C++.
The above are statements about OS design, not about languages.

Now i want to know that from what address value does the stack starts
and the heap actually start?
Neither C or C++ defines this.

What is at address 0(first address) in a program?
Neither C nor C++ define this either.

In other words,why the variables defined in the program have their
address as 1,2,3...( of course in hexadecimal)?
The address values are always like 0x00012ffc7 and likes..

Regards,
Yogesh Joshi

You aren't asking questions about programming languages you are asking
questions about OS design and/or compiler design. Languages don't define
where the stack starts or what is at a given address.

john

[Julián Albo]

yp*********@indiatimes.com wrote:

While readling the C and C++ literature i came to know that the OS
allocates separate protected memory space for each running program and
the program do not interfare into one another's address space.
Not very exact. That lietarure is about how C++ is implemented in some OS,
not about the language by itself. Try for example some C++ compiler for
ms-dos to see it.
Also the address space allocated for each program is totally relative.

Relative to what? The adresses are usually addresses, real or virtual
depending of the OS. Surely is possible a compiler that uses his own way of
addressing starting at 0, by offseting every memory access or something,
but probably nobody wtite a compiler like that. Maybe some day the parrot
guys will do.

--
Salu2

[mario.demiguel]

yp*********@indiatimes.com wrote:

Hello All,
While readling the C and C++ literature i came to know that the OS
allocates separate protected memory space for each running program and
the program do not interfare into one another's address space.
Also the address space allocated for each program is totally relative.

Now i want to know that from what address value does the stack starts
and the heap actually start?
That entirely depends on the system you are dealing with. Even with
that information, it may be hard to know exactly what address contains
the top of the stack.
What is at address 0(first address) in a program?
Usually the first instruction of your compiled/assembled program.
In other words,why the variables defined in the program have their
address as 1,2,3...( of course in hexadecimal)?
The address values are always like 0x00012ffc7 and likes..
I'm confused by what you are asking. Do you want to know why the
variables are at 0x00012ffc7 as opposed to 0x000000000?
Regards,
Yogesh Joshi

[Gordon Burditt]

>While readling the C and C++ literature i came to know that the OS

allocates separate protected memory space for each running program and
the program do not interfare into one another's address space.
Many OSs do this. MS-DOS and CP/M do not. I don't think Windows
3.1 did either. Certain implementations of UNIX-like OS on an 8086
did not (an 8086 doesn't have the hardware memory protection like
80[23456]86).
Also the address space allocated for each program is totally relative.
Not all systems have the hardware needed for virtual memory.
Now i want to know that from what address value does the stack starts
and the heap actually start?
Whereever they start. It's OS-dependent and may vary with the
particular program in question (it might be "just after the end of
the doohickey segment" or "just before the command-line arguments,
which take up a variable amount of space"). And C doesn't even
guarantee the existence of a stack, and it only guarantees the
existence of a heap if heap is defined as "that place from which
malloc() gets its memory".
What is at address 0(first address) in a program?
Who said address 0 is the first address in a program?

On a number of systems, such as many recent variants of UNIX, there
is no memory mapped there, and attempting to access it gives you a
smegmentation violation or similar program-aborting trap.
In other words,why the variables defined in the program have their
address as 1,2,3...( of course in hexadecimal)?
Who said they do? And not all variables are of size 1.
The address values are always like 0x00012ffc7 and likes..

Gordon L. Burditt

[ypjofficial]

sorry..the question here should be
In other words,why the variables defined in the program DON'T have
their
address as 1,2,3...( of course in hexadecimal)?
The address values are always like 0x00012ffc7 and likes..

sorry for creating confusion..

regards,
Yogesh Joshi

[ypjofficial]

sorry..the question here should be
In other words,why the variables defined in the program DON'T have
their
address as 1,2,3...( of course in hexadecimal)?
The address values are always like 0x00012ffc7 and likes..

sorry for creating confusion..

regards,
Yogesh Joshi

[Malcolm Dew-Jones]

yp*********@indiatimes.com wrote:
: Hello All,

: What is at address 0(first address) in a program?

in VMS on VAX, virtual address 0 was allocated to an inaccessible page to
help catch memory accesses from uninitialized pointers.

--

This programmer available for rent.

[John Harrison]

yp*********@indiatimes.com wrote:

sorry..the question here should be
In other words,why the variables defined in the program DON'T have
their
address as 1,2,3...( of course in hexadecimal)?
The address values are always like 0x00012ffc7 and likes..

If you want this question answered (which I guess you do) then you are
going to have to specify, which operating system, which processor, and
which compiler. Because the answer could be different depending on all
of these things.

Your question actually seems to be, given an OS with protected memory,
and a compiler which generates only code using relative addressing why
couldn't the compiler/linker/loader arrange it so that the stack starts
at address zero. Well indeed, but why should they either? Does it matter?

john

[E. Robert Tisdale]

Yogesh Joshi wrote:

While readling the C and C++ literature, I came to know that
the OS allocates separate protected memory space for each running program
and the programs do not interfere with one another's address space.
Also the address space allocated for each program is totally relative.
Not necessarily true.
Now, I want to know from what address value does the stack start
and the heap actually start?

What is at address 0(first address) in a program?

In other words,
"Why [do] the variables defined in the program
have their address as 1,2,3...( of course in hexadecimal)?"
The address values are always like 0x00012ffc7 and the like.

In the typical implementation, [virtual] memory is organized
as a set of sequential address from top to bottom:

00000000 top
00000001

[Skarmander]

E. Robert Tisdale wrote:
<snip>

> cat main.c

#include<stdio.h>

int main(int argc, char* argv[]) {
int* p = 0;
fprintf(stderr, "i*p = %d\n", *p);
return 0;
}

> gcc -Wall -std=c99 -pedantic -o main main.c
> ./main

Segmentation fault

Usually, you won't be able to access address 0
because it is reserved for the NULL pointer
or because it is reserved for the operating system
or both or some other reason.

Actually, the code posted is certainly a bad idea, invoking undefined
behaviour because you're dereferencing a null pointer. If you want
actual memory location 0, not whatever bit pattern your implementation
has picked for the null pointer, you'll have to be a little trickier:

int i = 0;
int* p = (int*) i;

This invokes unspecified behaviour, of course, and dollars to dougnuts
that this produces the exact same code on the majority of
implementations (which do equate memory location 0 and the null
pointer), but it beats undefined behaviour.

S.

[Jay Nabonne]

On Tue, 04 Oct 2005 15:30:04 -0700, ypjofficial wrote:

sorry..the question here should be
In other words,why the variables defined in the program DON'T have
their
address as 1,2,3...( of course in hexadecimal)?
The address values are always like 0x00012ffc7 and likes..

Here's a parallel question for *you*:

Why is your name not "Fred Flintstone"?

The answer: because your parents didn't give you that name, based on
multiple considerations.

The answer to your question is the same: they don't have those addresses
because, based on multiple considerations, the compiler/linker didn't give
them those addresses.

You will probably find more enlightenment studying why the decisions were
made that *were* made before asking why things couldn't be different.

- Jay

[Keith Thompson]

Skarmander <in*****@dontmailme.com> writes:

E. Robert Tisdale wrote:
<snip>

> cat main.c

#include<stdio.h>
int main(int argc, char* argv[]) {
int* p = 0;
fprintf(stderr, "i*p = %d\n", *p);
return 0;
}

> gcc -Wall -std=c99 -pedantic -o main main.c
> ./main

Segmentation fault
Usually, you won't be able to access address 0
because it is reserved for the NULL pointer
or because it is reserved for the operating system
or both or some other reason.

Actually, the code posted is certainly a bad idea, invoking undefined
behaviour because you're dereferencing a null pointer. If you want
actual memory location 0, not whatever bit pattern your implementation
has picked for the null pointer, you'll have to be a little trickier:

int i = 0;
int* p = (int*) i;

This invokes unspecified behaviour, of course, and dollars to dougnuts
that this produces the exact same code on the majority of
implementations (which do equate memory location 0 and the null
pointer), but it beats undefined behaviour.

The code you've shown invokes implementation-defined behavior.
The result of the conversion of an integer to a pointer "is
implementation-defined, might not be correctly aligned, might
not point to an entity of the referenced type, and might be a trap
representation" (C99 6.3.2.3p5). If you then attempt to dereference p,
the behavior is undefined (unless the implementation has defined 0 as a
valid address): "If an invalid value has been assigned to the pointer,
the behavior of the unary * operator is undefined" (C99 6.5.3.2p4).

Nasal demons are still a possibility.

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

[Skarmander]

Keith Thompson wrote:

Skarmander <in*****@dontmailme.com> writes:

E. Robert Tisdale wrote:
<snip>

> cat main.c
#include<stdio.h>
int main(int argc, char* argv[]) {
int* p = 0;
fprintf(stderr, "i*p = %d\n", *p);
return 0;
}
> gcc -Wall -std=c99 -pedantic -o main main.c
> ./main
Segmentation fault
Usually, you won't be able to access address 0
because it is reserved for the NULL pointer
or because it is reserved for the operating system
or both or some other reason.

Actually, the code posted is certainly a bad idea, invoking undefined
behaviour because you're dereferencing a null pointer. If you want
actual memory location 0, not whatever bit pattern your implementation
has picked for the null pointer, you'll have to be a little trickier:

int i = 0;
int* p = (int*) i;

This invokes unspecified behaviour, of course, and dollars to dougnuts
that this produces the exact same code on the majority of
implementations (which do equate memory location 0 and the null
pointer), but it beats undefined behaviour.

The code you've shown invokes implementation-defined behavior.
The result of the conversion of an integer to a pointer "is
implementation-defined, might not be correctly aligned, might
not point to an entity of the referenced type, and might be a trap
representation" (C99 6.3.2.3p5). If you then attempt to dereference p,
the behavior is undefined (unless the implementation has defined 0 as a
valid address): "If an invalid value has been assigned to the pointer,
the behavior of the unary * operator is undefined" (C99 6.5.3.2p4).

Nasal demons are still a possibility.

*If* address 0 is invalid, yes. We're sort-of assuming it's not,
otherwise, obviously, any attempt to get at location 0 is doomed.

My point was merely that getting at location 0 through a null pointer
was still a worse idea than doing it through a converted int.

It does all boil down to what is "more likely" to yield the desired
result. Let's not put money on that and agree you're basically on your
own if you want to do something like this, and if your implementation
agrees, good for you -- if not, try assembler...

S.

[Malcolm Dew-Jones]

yp*********@indiatimes.com wrote:
: Hello All,
: While readling the C and C++ literature i came to know that the OS
: allocates separate protected memory space for each running program and
: the program do not interfare into one another's address space.
: Also the address space allocated for each program is totally relative.

: Now i want to know that from what address value does the stack starts
: and the heap actually start?

: What is at address 0(first address) in a program?

: In other words,why the variables defined in the program have their
: address as 1,2,3...( of course in hexadecimal)?
: The address values are always like 0x00012ffc7 and likes..

One possible layout for your code will have the code itself loaded at a
low address. The stack will start at the end of the code and expand
towards higher addresses. The heap will start at a high address and
expand towards lower addresses.

In that layout, the address of variables on the stack will never have low
numbers because the lowest addresses contain the executable code.

That explanation is true for some systems, but is wrong for some others.
--

This programmer available for rent.

[Kenneth Brody]

Jay Nabonne wrote:

On Tue, 04 Oct 2005 15:30:04 -0700, ypjofficial wrote:

sorry..the question here should be
In other words,why the variables defined in the program DON'T have
their
address as 1,2,3...( of course in hexadecimal)?
The address values are always like 0x00012ffc7 and likes..

Here's a parallel question for *you*:

Why is your name not "Fred Flintstone"?

The answer: because your parents didn't give you that name, based on
multiple considerations.

The answer to your question is the same: they don't have those addresses
because, based on multiple considerations, the compiler/linker didn't give
them those addresses.

You will probably find more enlightenment studying why the decisions were
made that *were* made before asking why things couldn't be different.

Consider, for example, a platform where NULL is all-bits-zero, and the
implementors of the compiler/linker decided to start putting global
variables at address 1. (Starting them at zero is obviously "a bad
idea", as &first_global_variable==NULL.) This is still a bad idea,
as NULL pointers can still trounce over these variables. (What happens
if you dereference a NULL pointer to a struct?)

A practical reason for not placing anything near address zero is to
ensure that dereferencing NULL pointers cause a fault. (On platforms
that allow for such faults, of course.)

I've also seen a platform that, for some unexplained reason, acted as
if there were a read-only chunk of all-bits-zero memory at address zero,
allowing for NULL pointer dereferencing to succeed.

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Skarmander]

Kenneth Brody wrote:
<snip>

I've also seen a platform that, for some unexplained reason, acted as
if there were a read-only chunk of all-bits-zero memory at address zero,
allowing for NULL pointer dereferencing to succeed.

Ah, I know the answer to this one. It's so broken code like this won't
core-dump, even though it rightfully should:
printf("%s", p);
where p is, of course, 0, by accident or incompetence.

Likewise for all the other string functions: they'll do something
"reasonable". Heck, if all your data types use all-bits-zero as a
representation of their 0 value, it'll work for just about anything, and
give you a nice sensible default!

A splendid feature, until your program is compiled on a more sensible
platform, and crashes horribly.

S.

[Kenneth Brody]

Skarmander wrote:

Kenneth Brody wrote:
<snip>

I've also seen a platform that, for some unexplained reason, acted as
if there were a read-only chunk of all-bits-zero memory at address zero,
allowing for NULL pointer dereferencing to succeed.

Ah, I know the answer to this one. It's so broken code like this won't
core-dump, even though it rightfully should:
printf("%s", p);
where p is, of course, 0, by accident or incompetence.

I've seen better "solutions" to this by printing "<nil>" for NULL "%s"
values. This makes the cause more obvious.
Likewise for all the other string functions: they'll do something
"reasonable". Heck, if all your data types use all-bits-zero as a
representation of their 0 value, it'll work for just about anything, and
give you a nice sensible default!
I'm sure that was the logic[1] behind it.
A splendid feature, until your program is compiled on a more sensible
platform, and crashes horribly.

[1] FSVO.

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Simon Biber]

Kenneth Brody wrote:

Skarmander wrote:

Kenneth Brody wrote:
<snip>

I've also seen a platform that, for some unexplained reason, acted as
if there were a read-only chunk of all-bits-zero memory at address zero,
allowing for NULL pointer dereferencing to succeed.

Ah, I know the answer to this one. It's so broken code like this won't
core-dump, even though it rightfully should:
printf("%s", p);
where p is, of course, 0, by accident or incompetence.

I've seen better "solutions" to this by printing "<nil>" for NULL "%s"
values. This makes the cause more obvious.

And it's easy to implement without actually dereferencing the given
pointer, so you can keep your useful core-dump behaviour for when the
program actually does try to dereference a null pointer.

--
Simon.

[Mabden]

"Simon Biber" <ne**@ralmin.cc> wrote in message
news:43***********************@news.optusnet.com.a u...

Kenneth Brody wrote:

Skarmander wrote:

Kenneth Brody wrote:
<snip>

I've also seen a platform that, for some unexplained reason, acted asif there were a read-only chunk of all-bits-zero memory at address zero,allowing for NULL pointer dereferencing to succeed.
Ah, I know the answer to this one. It's so broken code like this won'tcore-dump, even though it rightfully should:
printf("%s", p);
where p is, of course, 0, by accident or incompetence.

I've seen better "solutions" to this by printing "<nil>" for NULL "%s" values. This makes the cause more obvious.

And it's easy to implement without actually dereferencing the given
pointer, so you can keep your useful core-dump behaviour for when the
program actually does try to dereference a null pointer.

And, if you read K&R, it is implied that Null and all bits zero are the
same. In a very long thread in a distant time of the "long ago", Keith
Thompson quite successfully showed how this is not a truth.

I suggest that the person who coded that software was under the same
misguided idea. It is however, not guaranteed by the standard.

[pete]

Mabden wrote:

And, if you read K&R,
it is implied that Null and all bits zero are the same.

And, if you read K&R,
you'll find that "Null" isn't in it.

What do you think you're talking about?
null character ?
null pointer ?
NULL ?

--
pete