accessing an array outside its bounds

[joint52]

Hello

This seems to work in my system, until variable 'i' reaches 15985, then
the program crashes.

My question is, why won't it crash sooner? How does it work?

And why am I able to set the value of rowptr[0][5100]?

Thanks
#include <stdio.h>
#include <stdlib.h>

int main(void)
{
int nrows = 5, ncols = 10;
int row, i;
int **rowptr;
rowptr = malloc(nrows * sizeof(int *));

for (row = 0; row < nrows; row++)
rowptr[row] = malloc(ncols * sizeof(int));

rowptr[0][5100] = 4;

for (i = 0; i < 30000; i++) {
printf("%d %d\n", i, rowptr[0][i]);
}
printf("%d\n", rowptr[0][5100]);
return 0;
}

[Eric Sosman]

jo*****@yahoo.com wrote On 04/07/06 11:02,:

Hello

This seems to work in my system, until variable 'i' reaches 15985, then
the program crashes.

My question is, why won't it crash sooner? How does it work?

Climb into your car, turn on the engine, put on
a blindfold, and start driving. You are quite likely
to crash, but there is no guarantee that you will crash
at the very instant you leave the driveway.

--
Er*********@sun.com

[Roberto Waltman]

On 7 Apr 2006 08:02:07 -0700, jo*****@yahoo.com wrote:

Hello
This seems to work in my system, until variable 'i' reaches 15985, then
the program crashes.

My question is, why won't it crash sooner? How does it work?
You are modifying memory that does not "belong" to you program. The
results are undefined. It may crash sooner, it may not crash at all,
it may crash at different times depending on what else is going on in
the system, it may cause something else to crash after you end this
program, and so on.
And why am I able to set the value of rowptr[0][5100]?

As before, C does not perform bound checks for array/memory access.
The compiler will produce code to compute a memory address and attempt
to write to it. There may even not be any real memory at that address.
Some operating systems / environments will detect this and terminate
your program, others will not. The behavior is again, undefined.

< code that access unallocated memory deleted >

[John F]

<jo*****@yahoo.com> schrieb im Newsbeitrag
news:11**********************@u72g2000cwu.googlegr oups.com...

Hello

This seems to work in my system, until variable 'i' reaches 15985,
then
the program crashes.
That's expected.
My question is, why won't it crash sooner? How does it work?
The same way every individual object in an array is accessed.
And why am I able to set the value of rowptr[0][5100]?
The compiler doesn't know how much memory you allocated.
Thanks
#include <stdio.h>
#include <stdlib.h>

int main(void)
{
int nrows = 5, ncols = 10;
int row, i;
int **rowptr;
rowptr = malloc(nrows * sizeof(int *));
You should check rowptr for NULL. If malloc fails it will make you
for (row = 0; row < nrows; row++)
rowptr[row] = malloc(ncols * sizeof(int));

rowptr[0][5100] = 4;

for (i = 0; i < 30000; i++) {
printf("%d %d\n", i, rowptr[0][i]);
}
printf("%d\n", rowptr[0][5100]);
return 0;
}

[John F]

Sorry ... hit <ENTER> with the wrong focus ...

"John F" wrote:

<jo*****@yahoo.com> wrote:

Hello

This seems to work in my system, until variable 'i' reaches 15985,
then
the program crashes.

That's expected.

My question is, why won't it crash sooner? How does it work?

The same way every individual object in an array is accessed.

And why am I able to set the value of rowptr[0][5100]?

The compiler doesn't know how much memory you allocated.

Thanks
#include <stdio.h>
#include <stdlib.h>

int main(void)
{
int nrows = 5, ncols = 10;
int row, i;
int **rowptr;
rowptr = malloc(nrows * sizeof(int *));

You should check rowptr for NULL. If malloc fails it will make you

access a NULL-pointer later on, which will give you a runtime error.

for (row = 0; row < nrows; row++)
rowptr[row] = malloc(ncols * sizeof(int));
Same goes here. Check rowptr[row] for NULL.
rowptr[0][5100] = 4;
Might cause an error or might not. Undefined behavior.
for (i = 0; i < 30000; i++) {
printf("%d %d\n", i, rowptr[0][i]);

Might cause an error or might not. Undefined behavior.

}
printf("%d\n", rowptr[0][5100]);
Might cause an error or might not. Undefined behavior.
return 0;
}

The compiler can't catch any violations of array-boundaries.

regards
John, who is sorry for the double post.

[Flash Gordon]

John F wrote:

Sorry ... hit <ENTER> with the wrong focus ...

"John F" wrote:

<jo*****@yahoo.com> wrote:

Hello

This seems to work in my system, until variable 'i' reaches 15985,
then
the program crashes. That's expected.

My question is, why won't it crash sooner? How does it work?

The same way every individual object in an array is accessed.

And why am I able to set the value of rowptr[0][5100]?

The compiler doesn't know how much memory you allocated.

Thanks
#include <stdio.h>
#include <stdlib.h>

int main(void)
{
int nrows = 5, ncols = 10;
int row, i;
int **rowptr;
rowptr = malloc(nrows * sizeof(int *));

You should check rowptr for NULL. If malloc fails it will make you

access a NULL-pointer later on, which will give you a runtime error.

*May* give you a runtime error. Alternatively it might not (and on some
systems it won't). It is undefined behaviour and anything can happen.

<snip correct stuff>
regards
John, who is sorry for the double post.

You were replying to your previous post correcting an error in it.
Nothing wrong with that.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc

[John F]

"Flash Gordon" wrote:

John F wrote:

Sorry ... hit <ENTER> with the wrong focus ...

"John F" wrote:

<jo*****@yahoo.com> wrote:
Hello

This seems to work in my system, until variable 'i' reaches
15985, then
the program crashes.
That's expected.

My question is, why won't it crash sooner? How does it work?
The same way every individual object in an array is accessed.

And why am I able to set the value of rowptr[0][5100]?
The compiler doesn't know how much memory you allocated.

Thanks
#include <stdio.h>
#include <stdlib.h>

int main(void)
{
int nrows = 5, ncols = 10;
int row, i;
int **rowptr;
rowptr = malloc(nrows * sizeof(int *));
You should check rowptr for NULL. If malloc fails it will make you access a NULL-pointer later on, which will give you a runtime
error.

*May* give you a runtime error. Alternatively it might not (and on
some systems it won't). It is undefined behaviour and anything can
happen.

Oh, yes. Thanks. Undefined is undefined ... ;-) Might make your PC
imitate "I'm singing in the rain...", might blow up your processor,
might fill your HDD with rubbish, might wash your dishes...
<snip correct stuff>

regards
John, who is sorry for the double post.

You were replying to your previous post correcting an error in it.
Nothing wrong with that.

Doesn't change that I'm sorry for it. Happens once in a while. Crappy
OE ...
I apologize for it every time. Just in case it _makes_ a difference.
Who knows? ;-)

regards
John

[Bill Pursell]

jo*****@yahoo.com wrote:

My question is, why won't it crash sooner? How does it work?
And why am I able to set the value of rowptr[0][5100]? <snip> #include <stdio.h>
#include <stdlib.h>

int main(void)
{
int nrows = 5, ncols = 10;
int row, i;
int **rowptr;

rowptr = malloc(nrows * sizeof(int *));

for (row = 0; row < nrows; row++)
rowptr[row] = malloc(ncols * sizeof(int));

rowptr[0][5100] = 4;

for (i = 0; i < 30000; i++) {
printf("%d %d\n", i, rowptr[0][i]);
}
printf("%d\n", rowptr[0][5100]);
return 0;
}

On many systems, malloc is implemented in such a way that
it doesn't have to enlarge your memory space with each call.
In other words, if you malloc 30 bytes and you don't currently
have enough space for the extra 30, malloc will increase
your heap by a large amout, probably some multiple of
the page size (~4k), and give you an address that has 30 bytes
available after (before) it. Later calls to malloc will then not
have call brk() to increase the heap, so they will be more
efficient. This means you've got more space than you think,
but you really shouldn't use it. No immediate segfault for
using it, but you're stepping on your own toes and asking for
trouble.

however, this is not a C question, and results will vary with
your system.

[Peter Shaggy Haywood]

Groovy hepcat jo*****@yahoo.com was jivin' on 7 Apr 2006 08:02:07
-0700 in comp.lang.c.
accessing an array outside its bounds's a cool scene! Dig it!

This seems to work in my system, until variable 'i' reaches 15985, then
the program crashes.

My question is, why won't it crash sooner? How does it work?
Barely a month goes by without someone asking this question. Had you
read the FAQ (http://www.eskimo.com/~scs/C-faq/top.html) beforehand,
as you should've done, or lurked for a month or two, as you should've
done, you would know the answer.
And why am I able to set the value of rowptr[0][5100]?

#include <stdio.h>
#include <stdlib.h>

int main(void)
{
int nrows = 5, ncols = 10;
int row, i;
int **rowptr;

rowptr = malloc(nrows * sizeof(int *));

for (row = 0; row < nrows; row++)
rowptr[row] = malloc(ncols * sizeof(int));

rowptr[0][5100] = 4;

for (i = 0; i < 30000; i++) {
printf("%d %d\n", i, rowptr[0][i]);
}
printf("%d\n", rowptr[0][5100]);
return 0;
}

With this code, anything might happen, including the code working as
you expect. You have undefined behaviour right, left & centre! That
means there is no defined behaviour for what you are doing. Any
behaviour exhibited by this code is "correct" (in the sense that it is
not wrong, because there is no wrong behaviour). You are inviting the
nasal demons to tea. Technically the compiler is allowed to contact
NASA via your modem and cause NASA computers to reprogram the Mars
Rover to blast off from Mars, fly back to Earth, land at your front
door, knock, wait for you to answer the door and then give you a smack
around the ear hole for invoking undefined behaviour. *Any* behaviour
is "correct".
You don't have the right to expect anything, except the unexpected.

--

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"?

[Richard G. Riley]

On 2006-04-12, Peter "Shaggy" Haywood <ph******@alphalink.com.au.NO.SPAM> wrote:

Groovy hepcat jo*****@yahoo.com was jivin' on 7 Apr 2006 08:02:07
-0700 in comp.lang.c.
accessing an array outside its bounds's a cool scene! Dig it!

This seems to work in my system, until variable 'i' reaches 15985, then
the program crashes.

My question is, why won't it crash sooner? How does it work?

Barely a month goes by without someone asking this question. Had you
read the FAQ (http://www.eskimo.com/~scs/C-faq/top.html) beforehand,
as you should've done, or lurked for a month or two, as you should've
done, you would know the answer.

It is all too frequent that people with problems are not aware of the
problem or understand what the issues is : for this reason they are
frequently unable to formulate the correct search criteria to find a
solution in the FAQ. To expect all posters to read and digest the FAQ
before posting is ludicrous : if all posters were familiar with the
standard and the c-faq then there would be almost no need for this
group.

[Mark McIntyre]

On Wed, 12 Apr 2006 17:42:15 +0200, in comp.lang.c , "Richard G.
Riley" <rg****@gmail.com> wrote:

It is all too frequent that people with problems are not aware of the
problem or understand what the issues is : for this reason they are
frequently unable to formulate the correct search criteria to find a
solution in the FAQ.
sure but...
To expect all posters to read and digest the FAQ
before posting is ludicrous :
It is? Why?

Is it ludicrous to expect people wanting to drive, to read a few
instruction manuals first?
if all posters were familiar with the
standard and the c-faq then there would be almost no need for this
group.

.... actually there'd be more utility from it. . Clue: this is not
comp.lang.learn.c-c++.

Mark McIntyre
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan