writing an interpreter for this programming language - segmentation error

i am writing a brainf**k interpreter for fun, but i'm getting a segmentation error and i do not understand why, could anyone tell me, please? i am quite new to c programming.
this is the c source code:

this is the updated code.
yes i am probably going to do that later, but does performance differ in any way or is it just the same when using ascii codes?

11-11-2012

std10093

The performance is affected by the heaviest operation of your code.This is that you read the file and then you read it again...The ascii code does not play a role in your's code performance.
Aslo see my edit in previous post for case 91

11-11-2012

nils8950

am i not allowed to modify it, or is it just a bad way to do it?

11-11-2012

std10093

The question is not clear to me.You are allowed to modify your own code.You write it :p

I suggest you take a second look at case 91.

11-11-2012

nils8950

i meant, does modifying i cause any problems at all?

11-11-2012

std10093

If the modifications made are correct,then the result will be correct.
If the modifications made are incorrect,then the result will be incorrect.

First make the code do what you want it to do and then improve performance.

11-11-2012

nils8950

my problem is just, i can't get it to work. thats why i posted here in the first place. i need help. the loops characters (cases 91 and 93) wont work

11-11-2012

c99tutorial

Try to break the problem down a little more, and explain what is your overall idea or algorithm. If you have a problem with cases 91 and 93, why not move them off into separate functions and then try to debug them separately.

For example, what exactly do you want to do in case 91? Are you trying to seek ahead to find where 93 occurs? Does 93 represent an "REP" instruction? Why not try it like thisÍ

Code:

case BF_FOR:
i = lookahead(file, BF_REP);
break;
// ...

And then define what BF_FOR, BF_REP are and what lookahead should do and what values it should return, etc.

11-11-2012

nils8950

Quote:

Originally Posted by c99tutorial

Try to break the problem down a little more, and explain what is your overall idea or algorithm. If you have a problem with cases 91 and 93, why not move them off into separate functions and then try to debug them separately.

For example, what exactly do you want to do in case 91? Are you trying to seek ahead to find where 93 occurs? Does 93 represent an "REP" instruction? Why not try it like thisÍ

Code:

case BF_FOR:
i = lookahead(file, BF_REP);
break;
// ...

And then define what BF_FOR, BF_REP are and what lookahead should do and what values it should return, etc.

What I am trying to do is, in case 91, look for the closest "]" character and continue the loop from there.
In case 93, I am trying to repeat to run the code between the "[" before the "]" and the "]"

11-11-2012

Click_here

This might not be causing any problems in your code, but I thought that I should mention it: If a file is opened and fails to open it returns "NULL". The actual value of NULL is implementation defined with its definition in the header stddef.

Most times it will be defined as ((void *)0), but you can not guarantee it.

Code:

if (file == 0)

/* should be */

if (file == NULL)

11-11-2012

christop

Quote:

Originally Posted by Click_here

Code:

if (file == 0)

/* should be */

if (file == NULL)

This is not a problem. A plain 0 in a pointer context is treated as a null pointer. Other equivalent forms are treated the same way, such as the expression (!file) which is equivalent to (file != 0), which is a valid comparison against a null pointer.