segmentation fault question

[b][red]This message was edited by tadghoastal at 2005-2-27 20:54:52[/red][/b][hr]
in this program im going through a maze the user enters the file for, but when i start messing around with the array the maze is in, i get a segmentation fault, and i dont know why. the code that causes the segmentation fault when the program is run is in red. any help will be greatly appreciated.


[code]#include

void processfile(FILE *ifp);
void traversemaze();

char array[21][21];
int trackx[200];
int tracky[200];

void main(){

// char mazearray[20][20];
// int track[200][200];
FILE *ifp, *ofp;
char mazefile[30];

printf("What is the name of the maze file?
");
scanf("%s", mazefile);

ifp = fopen(mazefile, "r");

processfile(ifp);


traversemaze();
}



void processfile(FILE *ifp){

int i, j;
for(i=0; i<=21; i++){
for(j=0; j<21; j++){
fscanf(ifp, "%c", &array[i][j]);
}
}
for(i=0; i<20; i++){ //make sure it read the file in
for(j=0; j<20; j++)
for(j=0; j<20; j++)
printf("%c", array[i][j]);
printf("
");
}
}


void traversemaze(){

int i, j, a, b;
int k, l; //for storing start position
char where;
for(i=0; i<20; i++){
for(j=0; j<20; j++){
where = array[i][j];
if(where=='S'){
break;
}
}
if(where=='S')
break;
}
}
if(where=='S')
break;
}
printf("
%d,%d
", i, j);
printf("%c", array[i][j]);

printf("%c", array[i][j+1]);
/* if(array[i][j]=='0'){
printf("whee");
j++;
printf("%c", array[i][j]);
}

if(array[i][j+1]=='0'){
printf("whee");
j++;
printf("%c", array[i][j]);
}*/
// k = i;
// l = j;

printf("whee");
[red] if(array[i-1][j]=='0'){ //starts with upper position
i--; //move to new spot
printf("%d", i);
trackx[a]=j; //stores where its been
tracky[b]=i;
a++;
b++;
array[i][j] = 'v'; //mark new spot as visited
}
else if(array[i+1][j]=='0'){ //downward position
i++; //move to new spot
trackx[a]=j; //stores where its been
tracky[b]=i;
a++;
b++;
array[i][j] = 'v'; //mark new spot as visited
}
else if(array[i][j-1]=='0'){ //left position
j--; //move to new spot
trackx[a]=j; //stores where its been
tracky[b]=i;
a++;
b++;
array[i][j] = 'v'; //mark new spot as visited
}
else if(array[i][j+1]=='0'){ //right position
j++; //move to new spot
trackx[a]=j; //stores where its been
tracky[b]=i;
a++;
b++;
array[i][j] = 'v'; //mark new spot as visited
}[/red]
/*else if(array[i-1][j]=='v'){ //getting out of dead ends
i=i-1; //move to new spot
trackx[a]=j; //stores where its been
tracky[b]=i;
a++;
b++;
array[i][j] = 'b'; //mark new spot as visited twice
}
else if(array[i+1][j]=='v'){ //getting out of dead ends
i=i+1; //move to new spot
trackx[a]=j; //stores where its been
tracky[b]=i;
a++;
b++;
array[i][j] = 'b'; //mark new spot as visited twice
}
else if(array[i][j-1]=='v'){ //getting out of dead ends
j=j-1; //move to new spot
trackx[a]=j; //stores where its been
tracky[b]=i;
a++;
b++;
array[i][j] = 'b'; //mark new spot as visited twice
}
else if(array[i][j+1]=='v'){ //getting out of dead ends
j=j+1; //move to new spot

trackx[a]=j; //stores where its been
tracky[b]=i;
a++;
b++;
array[i][j] = 'b'; //mark new spot as visited twice
}*/




}

[/code]

Comments

  • Code tags are your friend, [ code ] and [/ code ] (without the spaces.) Use them please.
    [italic][blue]To understand recursive, first you need to understand recursive[/blue][/italic]

  • [b][red]This message was edited by stober at 2005-2-28 2:38:31[/red][/b][hr]
    why don't you clean up that code so that it at least compiles without errors before posting. Some compilers will produce executables even though there are compile errors -- any attempt to run such programs will eventually crash the program or, worst case, crash the operating system and hard drive.

    Do not ignore the errors and warnings that your compiler produces!

    Example: variable a is used before being initilized in function traversemaze(). A good way to resolve this kind of problem it to initialize all variables when declared.


  • : Example: variable a is used before being initilized in function traversemaze(). A good way to resolve this kind of problem it to initialize all variables when declared.
    :
    :

    Good programming is to initialize variables before the first time they are used, which may not always be when they are declared. There are two reasons for this:

    -Main reason: the code becomes more modular. It is logical that the value is set in the same part of the code that will handle the value.

    -On applications in a tough environment, RAM might be corrupted from the time it is declared and initialized to the time it is first used (which might be days after declaration).

    Because of this, C++ allows variables to be declared anywhere in the code, and not just in the beginning of the local {}, as you are forced to do in C.
  • [b][red]This message was edited by shaolin007 at 2005-2-28 8:13:44[/red][/b][hr]
    disregard


  • [b][red]This message was edited by stober at 2005-2-28 7:45:2[/red][/b][hr]
    : [code]
    : for(j=0; j<20; j++){
    : [red]where = array[i][j]; this is going to be
    problem since i & j are 16bit and the array is 8bit in nature.[/red]
    [/code]
    I don't agree -- i and j are index values and have no relationship to the type of values that can be stored in the array. If you have an array of structs you surly wouldn't expect i and j to be of type struct? that doesn't make sense. index values are almost always integers or longs regardless of the data type of the array.





  • : [b][red]This message was edited by stober at 2005-2-28 7:45:2[/red][/b][hr]
    : : [code]
    : : for(j=0; j<20; j++){
    : : [red]where = array[i][j]; this is going to be
    : problem since i & j are 16bit and the array is 8bit in nature.[/red]
    : [/code]
    : I don't agree -- i and j are index values and have no relationship to the type of values that can be stored in the array. If you have an array of structs you surly wouldn't expect i and j to be of type struct? that doesn't make sense. index values are almost always integers or longs regardless of the data type of the array.
    :
    :
    [green]
    Yea your right, I skimmed over the code and didn't really pay attention.
    [/green]


  • : [b][red]This message was edited by stober at 2005-2-28 7:45:2[/red][/b][hr]
    : : [code]
    : : for(j=0; j<20; j++){
    : : [red]where = array[i][j]; this is going to be
    : problem since i & j are 16bit and the array is 8bit in nature.[/red]
    : [/code]
    : I don't agree -- i and j are index values and have no relationship to the type of values that can be stored in the array. If you have an array of structs you surly wouldn't expect i and j to be of type struct? that doesn't make sense. index values are almost always integers or longs regardless of the data type of the array.
    :
    :
    :
    :

    As stober says it doesn't matter which integer type the iterator is.

    Although, it might still be unnecessary to declare i as int when you know that it will only contain values 0 to 19. With a 32-bit compiler, you get 3 bytes of rubbish on the stack that never will be used. If you do the same on every place in a large program, it will require a lot of "dead" RAM memory.
  • :
    : Although, it might still be unnecessary to declare i as int when you know that it will only contain values 0 to 19. With a 32-bit compiler, you get 3 bytes of rubbish on the stack that never will be used. If you do the same on every place in a large program, it will require a lot of "dead" RAM memory.
    :


    Probably depends on the compiler, but ints usually have faster access time then other data types. For example, you could declare a loop counter as char, but the compiler has to upgrade it to int before it can be used.
  • : :
    : : Although, it might still be unnecessary to declare i as int when you know that it will only contain values 0 to 19. With a 32-bit compiler, you get 3 bytes of rubbish on the stack that never will be used. If you do the same on every place in a large program, it will require a lot of "dead" RAM memory.
    : :
    :
    :
    : Probably depends on the compiler, but ints usually have faster access time then other data types. For example, you could declare a loop counter as char, but the compiler has to upgrade it to int before it can be used.
    :

    How many ticks faster? One or two? :-)
    You won't notice any difference on todays processors, but you will notice the difference in used memory. As for alignment issues, they should be handled by the compiler, not the programmer.
    Also, the C standard knows nothing of hardware. If the processor would be 8-bit, then char would be faster than int, and so on.
  • : How many ticks faster? One or two? :-)

    You're right -- my mind sometimes is still in the 4 Mz 80x88 chip with 640K RAM where every clock tick counts!


    : You won't notice any difference on todays processors, but you will notice the difference in used memory.

    Naw -- with 2 Gig RAM nobody would notice the difference between a 1 byte loop counter or a 4-byte int loop counter, unless your program has several trillion of these loops.


    : As for alignment issues, they should be handled by the compiler, not the programmer.

    Not entirely true: agree that alignment of the register values is not under programmer's control. But other kinds of data alignment (and you probably already know this but others may not), such as on byte or word boundries, is at the discretion of the programmer.


Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories