Thread: Simple Math

This code worked perfectly at school in the lab but when I copied it to notepad and sent it to myself via email and pasted the code into Dec-C++ it no longer worked. When I run the program it should allow me to type a number such as four and give me an answer (in this case six). Instead of working and giving me the correct answer when i type in the number and press enter the command prompt window closes. I tried to fix it last night but I am not sure what could be wrong.

Code:

#include <stdio.h>
int sum(int n)
{
if(n==0)
    return(0);
    else 
    return(sum(n-2)+n);
}
main()
 
 {
          int N;
          scanf("%d",&N);
          printf("The sum is %d.\n", sum(N));
          }

Originally Posted by Adak

remove the "sum" in the return statement of function sum.

If N==1, then all is well, otherwise, the N will never be 0, and continue to recursively call sum().

Yeah, I think it will only work with even inputs. Though I hate recursion.

It's definitely ending, which is why his command prompt is going away, so it's not stuck in an infinite recursive loop with no base case being met.

Originally Posted by Syndacate

Yeah, I think it will only work with even inputs. Though I hate recursion.

It's definitely ending, which is why his command prompt is going away, so it's not stuck in an infinite recursive loop with no base case being met.

If n equals 1:

n-2+n will equal 0, and the function will return on the next recursive call it makes to sum()

If n equals 2 or more:

n-2+n will equal 2 or more, and the function will continue recursive calls to sum().

Yes?

Thanks! it works!!! Always fast responses! If only there was a rep system here so i could +rep everyone helping me. This is a great community.

Originally Posted by Elysia

Don't ever use gets.

The indentation could use some work, too, and main should have a return type of 0.

I wouldn't, in practice, but this is for some school project, I doubt his professor will buffer overflow his submitted program to execute malicious code on his own computer *confused." For what he's using it for I would say it's fine, simple enough and straight enough to the point if he's still learning.

Originally Posted by Adak

If n equals 1:

n-2+n will equal 0, and the function will return on the next recursive call it makes to sum()

If n equals 2 or more:

n-2+n will equal 2 or more, and the function will continue recursive calls to sum().

Yes?

I don't know, I suck at recursion - I don't use it.

I would think:

Passing it 2, initially:
sum(n-2) where n = 2 would be sum(0) (return 0) + 2 would output 2.
sum(n-2) where n = 3 would be sum(1)+3 >> sum(-1)+1 >> sum(-3)+-1 and it goes forever in a downward recursive spiral - I can see that.
But for 4:
sum(n-2) where n = 4 would be sum(2) >> sum(0) (return 0) + 2 >> 6.

I see valid answers for 0, 2, 4..one would say via induction that that's enough to prove that it works for all even numbers. Though as I said, I really do suck at recursion, I don't use it, so I could obviously be very wrong. An explanation would be much appreciated, though.

Originally Posted by new_ink2001

Amphibian,

I assume that you brought it home to a Microsoft Windows computer. If that is indeed the case, then this line will produce the "Press any key to continue . . ." prompt:

Code:

system("pause");

The 'pause' command is a component of the DOS shell (batch programming) facilities. I think it's been around since...version 4, and according to Van Wolverton Running MS-DOS 6th Ed. Washington: Microsoft Press 1993 ISBN 1-55615-542-5, prior to that version would produce the message: "Strike a key when ready...." The newer versions of Windows (DOS) are using something called 'PowerShell' now, and I think the implementation uses PERL for the batch processing language (?).

The 'system()' function call, according to Paul S. Wang An Introduction to ANSI C on UNIX Boston: PWS Publishing 1993 ISBN 0-534-14232-X, is used to "[allow] execution of shell-level commands from within C programs...." He gives examples like copying files and the like. The inclusion of 'stdio.h' seems to make the library function available, but I suppose that depends on the compiler. I would confidently expect to find it in 'stdlib.h.'

Best Regards,

New Ink -- Henry

Good info. I'm ........ed at myself for not knowing that, I use "pause" all the time in batch scripts, and I use system() from time to time in UNIX based systems, typically to call scripts or what-have you. Can't believe I didn't put 2 & 2 together. A lot more eloquent than through a random "read" in there such as gets();.

Originally Posted by pianorain

This is correct. Non-negative even numbers terminate; all other numbers are handled poorly.The point is that if he's still learning, he should learn the 'right' way to do it. gets() is almost never the 'right' way.

Oh, ok, at least I get the simple recursive ones right sometimes :-P.

Fair enough, I guess the way I see it is it's simply a factor of his environment. It wouldn't be an issue if he manually opened a command prompt, and if this was a real algorithm for a system's back-end or for a GUI application it wouldn't matter anyway. So I guess the way I see it is it's simply a matter of his way of execution, which wouldn't be practiced in the real world, y'know? But I do understand where you're coming from.

you could try code::blocks (an IDE), it keeps the console window open, no need for extra code.

Originally Posted by Elysia

The thing is: there is a difference between a simplified model and a dangerous model.
Some things are fine to use if you're a newbie--like not handling input correctly. But some things are just outright dangerous, regardless if you're used in a controlled environment or not. gets is one of those.
This leads to the topic of buffer overruns, which is a very real problem that plagues C today. Learning how to handle it is critical, regardless of where, how or why you're programming. Therefore using gets is always bad.
Then there's the fact that gets will most likely be removed in the next C standard! The simple fact is that there's an easy and safe alternative: fgets. There is nothing fgets cannot do that gets can.

I realize the rationale behind it though I still disagree, especially about the "critical" aspect.

While it's true, buffer overruns are a very feasible exploit, for a new programmer using it in a controlled env (an OS), using it as a standard user, I still don't see any issues. Sure, I would never advocate using it, but I wouldn't say it's as critical as you believe. What's the real danger, if somebody roots his computer they can execute a trojan they dropped in automagically? Sure, but I'd consider the trojan drop off and the rooting of the system larger problems to begin with. As for it accessing sys resources in a very negative way. In many mainstreamed OS's, Windows especially, most of that stuff is protected. There's no way a buffer overrun from an app level program could slip into HDD driver code and start eating data or anything malicious like that.

I guess I fail to see that in beginning programming (ie. an echo program or some recursive proof of concept program) the harm that can be done by executing it in user-land under a non-root user. Sure, it can overflow and .. probably get seg faulted, but the largest issue I see with that is the size of the core dump stack trace it will leave, y'kno? Maybe an example (real world, beginning programming, app level, non-root, protective OS) can change my outlook on it.

Again, I don't advocate the use of gets() - not by a landslide - but if some beginner chooses to use it in their programs which add two values together from stdin and print the results I don't see the critical aspects to it.

I'd be really surprised if they removed it from the standard, despite its exploits and other possible issues, that's a big shot to backwards compatibility.