why does thus cause a segmentation fault?

[The Derfer]

This code causes a segmentation fault when I run using ./a.out

It compiles fine though.


#include <stdio.h>
int main()
{
int ix;
const int array_size = 10;
int ia[array_size];

for (int ix= 0 ; ix < array_size ; ++ix );
ia[ix]=ix;

printf("%d","%d",ix,ia[ix]);
}

 

[crisgoogle]

This code causes a segmentation fault when I run using ./a.out

It compiles fine though.

#include <stdio.h>
int main()
{
int ix;
const int array_size = 10;
int ia[array_size];

for (int ix= 0 ; ix < array_size ; ++ix );

Here, by sticking "int" inside the for(), you're declaring a _new_
variable called ix that's used to count your loop, has scope
only within the loop, and hides the original ix that you declared.

ia[ix]=ix;

printf("%d","%d",ix,ia[ix]);

}

And then you use the original ix, to which you never assigned a
value, to index your array. BOOM.

 

[David Resnick]

This code causes a segmentation fault when I run using ./a.out

It compiles fine though.

#include <stdio.h>
int main()
{
int ix;
const int array_size = 10;
int ia[array_size];

for (int ix= 0 ; ix < array_size ; ++ix );
ia[ix]=ix;

printf("%d","%d",ix,ia[ix]);

}

Maybe you meant something more like this? Uses variable array sizes.
You problems include stray ';', missing braces, extra ',', etc...

#include <stdio.h>
int main()
{
int ix;
const int array_size = 10;
int ia[array_size];

for (ix= 0 ; ix < array_size ; ++ix )
{
ia[ix]=ix;
printf("%d %d\n",ix,ia[ix]);
}
return 0;
}

-David

 

[Seebs]

This code causes a segmentation fault when I run using ./a.out

That's nice.

int ix;
const int array_size = 10;
int ia[array_size];

for (int ix= 0 ; ix < array_size ; ++ix );

The semicolon here means that this is a loop
which does nothing but set ix equal to array size.

ia[ix]=ix;

You now try to set element 10 of an array which has
elements 0 through 9.

-s

 

[Seebs]

Here, by sticking "int" inside the for(), you're declaring a _new_
variable called ix that's used to count your loop, has scope
only within the loop, and hides the original ix that you declared.

Good catch, I missed that part.

Given the name and the code, and the sheer density of various
errors, I'm assuming this is just one of the regular trolls messing
with us.

-s

 

[Keith Thompson]

This code causes a segmentation fault when I run using ./a.out

It compiles fine though.


#include <stdio.h>
int main()
{
int ix;
const int array_size = 10;
int ia[array_size];

for (int ix= 0 ; ix < array_size ; ++ix );
ia[ix]=ix;

printf("%d","%d",ix,ia[ix]);
}

Apart from the other errors, note that ia is actually a VLA (variable
size array). An object declared "const" is not a constant in C; "const"
merely means that it's read-only, not that its value is determined at
compile time. For example:
const int r = rand();
is valid.

In practice, the compiler will probably treat it the same, or nearly so,
as if the size were constant, but it might be better to actually
make it constant, either:
#define ARRAY_SIZE 10
or
enum { array_size = 10 };

A minor point: "int main()" should be "int main(void)".

Proper indentation is important. Indentation should reflect the
structure of your program. If you have the "indent" tool, try
running your code through, for example, "indent -kr". That would
have made it more obvious that the statements following the for
loop are not controlled by it. (Read the documentation; it creates
a backup and clobbers the input file, which is somewhat unusual
behavior for such a tool.)

 

[Vincenzo Mercuri]

This code causes a segmentation fault when I run using ./a.out

It compiles fine though.

With gcc you get one warning, in the best case.
Always compile with at least "gcc -Wall -Wextra". I'd also suggest
"-Wshadow", that would have been very helpful in this case.


--
Non puoi insegnare qualcosa ad un uomo. You cannot teach a man anything.
Lo puoi solo aiutare -- Galileo Galilei -- You can only help him
a scoprirla dentro di sé. discover it in himself.

Vincenzo Mercuri

 

[Ian Collins]

Good catch, I missed that part.

Given the name and the code, and the sheer density of various
errors, I'm assuming this is just one of the regular trolls messing
with us.

You're probably correct, but that won't stop more people answering!

 

[Uno]

Good catch, I missed that part.

Given the name and the code, and the sheer density of various
errors, I'm assuming this is just one of the regular trolls messing
with us.

Yeah, seebs, we who gladly call ourselves different than you sit around
to think of new ways to waste everybody's time. Have you yelled at the
paperboy yet today?

 

[Geoff]

This code causes a segmentation fault when I run using ./a.out

It compiles fine though.


#include <stdio.h>
int main()
{
int ix;
const int array_size = 10;
int ia[array_size];

for (int ix= 0 ; ix < array_size ; ++ix );
ia[ix]=ix;

printf("%d","%d",ix,ia[ix]);
}

Then your compiler is defective. There are numerous errors.
Even if it did compile without errors, that is no guarantee of correct
execution. That's what a debugger is for.

This is probably what you intended:

#include <stdio.h>

#define ARRAY_SIZE 10

int main()
{
int ix;
int ia[ARRAY_SIZE];

for ( ix = 0; ix < ARRAY_SIZE; ++ix )
{
ia[ix] = ix;
printf("%d,%d\n", ix, ia[ix]);
}
return 0;
}

 

[Mr. Buffoon]

Change to a better compiler!
A decent compiler automatically fixes your bugs.

 

[Peter Nilsson]

It compiles fine though.

#include <stdio.h>
int main()
{
int ix;
const int array_size = 10;
int ia[array_size];

for (int ix= 0 ; ix < array_size ; ++ix );
ia[ix]=ix;

printf("%d","%d",ix,ia[ix]);
}

Then your compiler is defective.

In what way? No diagnostic is required under C99.

 

[Keith Thompson]

This code causes a segmentation fault when I run using ./a.out

It compiles fine though.


#include <stdio.h>
int main()
{
int ix;
const int array_size = 10;
int ia[array_size];

for (int ix= 0 ; ix < array_size ; ++ix );
ia[ix]=ix;

printf("%d","%d",ix,ia[ix]);
}

Then your compiler is defective. There are numerous errors.

Yes, there are numerous errors, but none that a conforming compiler is
required to diagnose.

[...]

Even if it did compile without errors, that is no guarantee of correct
execution. That's what a debugger is for.

It's also what a compiler with warnings enabled is for. "Correct"
execution of a program whose behavior is undefined wouldn't prove
anything significant. (Trolls: No, I am not saying that programmers
should not use debuggers, don't be ridiculous.)

[snip]

One of the most important things to know about C is how many
obviously wrong things you can do that the implementation isn't
required to warn you about. One of the most important things to know
about any particular C compiler is how to get it to warn you anyway.

 

[Mark Bluemel]

This code causes a segmentation fault when I run using ./a.out

You crossed the streams. Dr Spengler told you before not to do that.

 

[Wolfgang.Draxinger]

Am Thu, 23 Sep 2010 17:39:17 -0700

One of the most important things to know about C is how many
obviously wrong things you can do that the implementation isn't
required to warn you about. One of the most important things to know
about any particular C compiler is how to get it to warn you anyway.

The other important thing to know about, are the ways in which
nonconforming but for some reason working-with-a-particular-
implementation-on-a-certain-platform programs may or will break if
you're fixing their mistakes. Getting those right can be quite
painful.

BTDT just this month: Some old code, which had already been fixed and
sanatized in newer versions of the program. But some old project was
tied to a particular old version. First I tried to fix some of the more
obvious mistakes to get it compile on a recent compiler with several
warnings turned on by default. The result was that some numerical code
may ran into infinite loops and yielded wrong (read "out of error
margin") results.

The morale: Don't write nonconforming, implementation dependent,
undefined behaviour triggering code in the first place. Use the proper
types given you by stdint.h don't try to outsmart the compiler and
don't rely on a particular outcome of undefined behaviour. Later
maintainers thank you.


Wolfgang

 

[Willem]

Seebs wrote:
)> This code causes a segmentation fault when I run using ./a.out
)
) That's nice.
)
)> int ix;
)> const int array_size = 10;
)> int ia[array_size];
)>
)> for (int ix= 0 ; ix < array_size ; ++ix );
^^^
) The semicolon here means that this is a loop
) which does nothing but set ix equal to array size.
)
)> ia[ix]=ix;
)
) You now try to set element 10 of an array which has
) elements 0 through 9.

Not quite.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Seebs]

Seebs wrote:
)> for (int ix= 0 ; ix < array_size ; ++ix );
^^^
) The semicolon here means that this is a loop
) which does nothing but set ix equal to array size.

Not quite.

Right you are. My eyes were glazed over by the sheer error density.

-s