Seg Fault

[Gamingphreek]

Can someone please tell me why my recursive call is resulting in a segmentation fault. Language is C.

void imm5Bin( int num5 )
{
if( num5 == 1 )
{
printf( "%d", num5 );
}

else
{
imm5Bin( num5/2 );
printf( "%d", (num5)%2 );
}
}

 

[Markbnj]

The most likely reason would be that num5 == 1 never evaluates true, and you run out of stack space due to infinite recursion.

 

[Gamingphreek]

Oh. My. Goodness.

I feel so horribly dumb right now for forgetting the base case of 0.... Wow - I really should stop my project and sleep every once in a while lol. Jeez

Thanks so much,
-Kevin

 

[Markbnj]

Heh, been there, done that . My favorite is using = instead of == in a conditional, staring at it for an hour without seeing it, and then calling a colleague over to look too.

 

[tfinch2]

Originally posted by: Markbnj
Heh, been there, done that . My favorite is using = instead of == in a conditional, staring at it for an hour without seeing it, and then calling a colleague over to look too.

DIE!

 

[txrandom]

Was your solution correct? Integers are just truncated in C not rounded correct? I don't think you would need a 0 base case. Since you are dividing by 2 and your present base case is 1, you should never be able to get an integer that would truncate to 0.

Like 3/2 = 1.5 = (int) 1 thus recursion would stop.

 

[Gamingphreek]

Originally posted by: txrandom
Was your solution correct? Integers are just truncated in C not rounded correct? I don't think you would need a 0 base case. Since you are dividing by 2 and your present base case is 1, you should never be able to get an integer that would truncate to 0.

Like 3/2 = 1.5 = (int) 1 thus recursion would stop.

Integers in C/C++ and Java (etc...) all merely round down. I don't think they truncate. .5 would round to 0 for instance. The base 0 case solved the seg fault though

-Kevin

 

[Crusty]

Originally posted by: Gamingphreek

Originally posted by: txrandom
Was your solution correct? Integers are just truncated in C not rounded correct? I don't think you would need a 0 base case. Since you are dividing by 2 and your present base case is 1, you should never be able to get an integer that would truncate to 0.

Like 3/2 = 1.5 = (int) 1 thus recursion would stop.

Integers in C/C++ and Java (etc...) all merely round down. I don't think they truncate. .5 would round to 0 for instance. The base 0 case solved the seg fault though

-Kevin

Well, technically C/C++ truncate the number, it's easier for a CPU to truncate instead of doing a rounding calculation. Either way, "rounding down" will produce the same result as truncating the number. In order to round the result of an integer division the CPU would have to use floating point division instead which is more complex than integer division and then apply the rounding. By using integer division you don't have the precision to even calculate the decimal portion of the result, it's just discarded. That's why when you DO want a floating point result you have to typecast the operands to float/double, forcing the CPU to do floating point division.

 

[Gamingphreek]

Originally posted by: Crusty

Originally posted by: Gamingphreek

Originally posted by: txrandom
Was your solution correct? Integers are just truncated in C not rounded correct? I don't think you would need a 0 base case. Since you are dividing by 2 and your present base case is 1, you should never be able to get an integer that would truncate to 0.

Like 3/2 = 1.5 = (int) 1 thus recursion would stop.

Integers in C/C++ and Java (etc...) all merely round down. I don't think they truncate. .5 would round to 0 for instance. The base 0 case solved the seg fault though

-Kevin

Well, technically C/C++ truncate the number, it's easier for a CPU to truncate instead of doing a rounding calculation. Either way, "rounding down" will produce the same result as truncating the number. In order to round the result of an integer division the CPU would have to use floating point division instead which is more complex than integer division and then apply the rounding. By using integer division you don't have the precision to even calculate the decimal portion of the result, it's just discarded. That's why when you DO want a floating point result you have to typecast the operands to float/double, forcing the CPU to do floating point division.

Ah that makes sense then. I remember my first program in C++ back in my Junior year of High School. Make a rounding program

 

[Ken g6]

Originally posted by: Crusty
...Either way, "rounding down" will produce the same result as truncating the number.

Let me dispel this before it gets too far. "Rounding down" will produce the same result as truncating a positive number:

5/3 in math = 1.6666666...
floor(5/3) = 1
5/3 in C = 1

But for a negative number:

-5/3 in math = -1.6666666...
floor(-5/3) = -2
-5/3 in C = -1

So be careful 'round negative numbers!

 

[Crusty]

Originally posted by: Ken g6

Originally posted by: Crusty
...Either way, "rounding down" will produce the same result as truncating the number.

Let me dispel this before it gets too far. "Rounding down" will produce the same result as truncating a positive number:

5/3 in math = 1.6666666...
floor(5/3) = 1
5/3 in C = 1

But for a negative number:

-5/3 in math = -1.6666666...
floor(-5/3) = -2
-5/3 in C = -1

So be careful 'round negative numbers!

Obviously that's true, but in the OP's context it won't matter