Printable View
Hi,
I'm new with C programming and I would like to know the code that would allow me to enter numbers like 987654321 and put each of them in an array [0] --> 9, [1]-->8...
do
{ puts("Enter your nine number ");
gets(number);
AnalyseNumber //where I want my array with my numbers
Thanks
gets() is evil and should never be used. Use fgets() instead. But if you've got your number string you could simply do:
The - '0' effectively removes the shift inherit in the ASCII values (e.g. it turns '7' into 7, '5' into 5, etc.).Code:for(i = 0;i < 9;++i)
array[i] = number[i] - '0';
gets() is easy and doesn't save the new line character. Never use it in any serious programs, but it's okay for quick or test programs that don't last long and only you use.Quote:
gets() is evil and should never be used.
I'd still stay away from it. Especially if you were to be a beginner at C and weren't sure of what could go wrong with it.
Sure, if all that everyone say is gets() is evil so you don't ever find out what could go wrong with it. ;) If you know what could go wrong, you can use it safely. If you don't know what could go wrong, you can still get away with using it in throw away programs.
For nevrax, here's why gets() is "evil". :rolleyes: It only takes one parameter, the array to put a string into, but the array has a finite size and gets() has no way of telling what that size is. So gets() assumes that the array is big enough and just copies everything it gets even if the array isn't big enough. That's called buffer overrun, and it can be used by hackers to circumvent the security on a computer and break into it.
But if you're the only one who uses your program, even if you don't know the size of an array that you declared, chances are good that you're not trying to break into your own computer, right? :D It's just that easy. Not really as evil as you were led to believe, huh?
fgets() is not much harder to use. It's probably a good idea for new programmers to get used to using it in test programs, so when they work on "serious" projects, they don't have to worry about remembering how to use it.
> chances are good that you're not trying to break into your own computer, right?
How about learning to do it the right way all the time, rather than second guessing who's going to use it?
If you do it the right way out of habit, then it will be right when it matters, not when you can be arsed to make it right.
Here's a fun problem, explain how fgets() is not much harder to use to a beginner when he encounters it:Quote:
fgets() is not much harder to use.
Code:fgets( password, sizeof password, stdin );
if ( strcmp( password, "opensezme" ) == 0 ) {
// let the user in
} else {
// mean error message
}
You're assuming that gets() is wrong. It's like saying that strcpy() is wrong for the same reason, or calloc is wrong because 0 filling doesn't mean initializing to 0, or printf is wrong because it's not type safe, or scanf is wrong because it's not the inverse of printf. How many legitimate functions do you ignore because of some imagined sense of right and wrong, Salem?Quote:
How about learning to do it the right way all the time, rather than second guessing who's going to use it?
strcpy() is not wrong in the same sense because you can take care to never mess up with it. You can always be aware of the sizes of the strings in question. Again, with printf(), same type of argument. If something goes wrong with printf(), you messed up as a programmer.
With gets(), you are totally at the mercy of whatever happens to be coming in through stdin. scanf() is also bad if you use it improperly, and even if you use it properly, you're still somewhat at the mercy of whatever stdin is holding for you.
Safest way of reading input is generally to use fgets().
I know there is no possible way to make gets() safe in any circumstance you care to mention.
You can do what the hell you like in your own code, but for sure you're never going to get away with using gets() on a forum without someone hauling your ass over the hot coals for it.
> Here's a fun problem, explain how fgets() is not much harder to use to a beginner when he encounters it:
Awww - and the solution is so easy to fix.
Is it that hard to explain one extra line of code?
It's the same way with gets(). :) It's perfectly safe if you control the input and can guarantee that it all fits in the array. The only difference is that gets() is "evil" so you make an exception.Quote:
strcpy() is not wrong in the same sense because you can take care to never mess up with it. You can always be aware of the sizes of the strings in question. Again, with printf(), same type of argument. If something goes wrong with printf(), you messed up as a programmer.
I wrote the program so I know how big the array is, I'm the only one who uses the program so I control the input, and I know the problem with gets() so I make sure not to overrun the buffer. That's my circumstance, and it's perfectly safe no matter how much hand waving you do.Quote:
I know there is no possible way to make gets() safe in any circumstance you care to mention.
So that stuff about doing it right out of habit was a load of bull? If the only use of gets() you care about is code posted here, then that kind of makes you a hypocrite. You rant and rave about it, but at the end of the day, it doesn't matter if people use it as long as you don't see. Your argument is very convincing. :rolleyes:Quote:
You can do what the hell you like in your own code, but for sure you're never going to get away with using gets() on a forum without someone hauling your ass over the hot coals for it.
At least 2 lines if you don't do something obscure and use good formatting, an extra variable if you want it to be fast, and yes, it's hard to explain to a beginner if you want them to understand the problem and the solution so they don't do it again. Beginners won't want to write code if they think it's useless, and that's useless when they look at how easy gets() is.Quote:
Awww - and the solution is so easy to fix.
Is it that hard to explain one extra line of code?
There is a reason why it is considered deprecated.Quote:
Originally Posted by Noir
For you to write one or two lines more for fgets() to avoid any crashes and bugs later can hardly take too much of your time. Why you would not want to do that, and why you would encourage new programmers to get used to using a deprecated function is beyond me.
If you can control the input, you are correct, it is "safe", even though you can still crash the program, however. If you want to write programs that you can crash, that is your right, but understand that you are on your own for that. If your test programs don't work when you are sloppy in your coding, don't be surprised. Many people will not want to help debug those type of programs, and on top of it, some may say thay you deserve any errors that you get.Quote:
Originally Posted by NOIR
Don't be obtuse. We can't stop you from writing garbage on your own. If you want to write spaghetti code with goto, for example, we can't stop you from doing it, even though we will tell you it's wrong. Same with any other bad coding practice. If you post it on the forums, you obviously shouldn't expect anyone to help you with it, and we will tear you apart for posting it when you know better.Quote:
Originally Posted by NOIR
When they are taught to use gets(), they will think it's the proper way to read a string. If taught otherwise from the start, they can save themselves many problems resulting from pointer/buffer issues.Quote:
Originally Posted by NOIR
I think what you're forgetting is that a lot of good books on C, and classes as well, teach using gets() and scanf().
Your arguments are all logical, BUT they ignore the reality of what the students are coming here with in their class notes, and in their books.
I believe a beginner should learn and work with gets() and scanf(), just to become somewhat familiar with them AND with their potential for trouble. THEN as intermediate students of C, they go on to practice fgets() and etc.
I don't see the point of "raking someone over the hot coals" for using or explaining code with gets() or scanf(). A learning program is just for learning - no commercial robustness is needed, or should be expected.
I can confirm that most tutorials and C classes, especially when dealing with people who first venture into the world of programming, only mention scanf() for formatted and gets() for any other input method. However, they almost always mention that there is a problem with these two and only later on come back on that exact problem and explain how to do it "better".
In the K&R The C Programming Language, they don't mention gets() and puts() at all, apart from the function listing at the end. They start by using only getchar() and later on formatted input with scanf, then immediately explain fgets().
However, a beginner doesn't care about "safe" code as long as his program runs 99% of the time or even worse, corresponds to his homework assignment. In fact, some stuff, as you can see here is terribly hard to explain with all the details you have to watch out for, that beginners start losing their hope because they think C is too hard.
As long as you mention that there's a problem with buffer overflows, I don't think it's a problem to explain something with gets() but most of the time I decide based on the experience grade of the op.
Yeah, it goes without saying that we should teach beginners why gets() should to be avoided so they can decide when to listen. I can't believe that people here really think a "do it this way or else" attitude promotes learning, so they probably just aren't expressing themselves well. ;)
> If the only use of gets() you care about is code posted here, then that kind of makes you a hypocrite.
Well obviously because I have no way of controlling (or even commenting) on what you do in private.
Just so you know, I always use fgets(), no matter how trivial the program is.
> You rant and rave about it, but at the end of the day, it doesn't matter if people use it as long as you don't see.
People are free to read the arguments, but if the only way for you to discover gravity is by jumping off a cliff, then that is what you're going to have to experience for yourself.
Eventually, this "fast and loose" approach of yours will bite you one too many times, then you'll figure out the correct way to do things.
> How many legitimate functions do you ignore because of some imagined sense of right and wrong, Salem?
Lots of them - especially if I'm coding to MISRA standards.
this made my day :)Quote:
Originally Posted by Salem
Just to weight in on a heavy conflict. What does fgets() use or do differently then scanf() and gets(). Also back in the day when I was learning C at my old summer job, the book "C for dummies" quickly told the user after 1 page of using gets() that there is bug and not to use it. As I would like to say Noir has the upper hand in the debate based on his iambic pentatonic blank verse but Salem is right. Salem who does enjoying the coals of Satan behind the cynicism is really telling us (and those who agree with him) that well why would you want to be using something that will only cause you pain in the end, for an extra line of code you can achieve a higher understanding of C and prepare yourself for the future. Now I am not sure as to what the real issues here are about gets() and scanf() but if there is some form of error then I have no choice but to discontinue using them. I don't mind the extra line of code and if it going to make my life easer in 5 years then why waits 5 years to get comfortable with it? I must say it was comical how Noir attacked Salem but Noir who is new and has little to stand on VS the god of C in my book; it just isn't a fair fight! Now quzah VS Salem, that’s a fight I would pay to see.
gets() and fgets() treat the new line character different. gets() reads it and throws it away, so the string doesn't ever have a new line at the end, and fgets() reads it and copies it to the string, so the string sometimes has a new line at the end and sometimes it doesn't. scanf() does everything different and has more problems than just a new line.
That's not the point. Yeah, gets() is a really bad choice in code you're going to keep or let others use. If you already know the problems and the solutions, that doesn't give you a higher understanding of C in toss away programs, it just gives you that much more boilerplate to write. If you don't know the problems or the solutions, Salem and friends want you to blindly use fgets() and not bother learning at all. Read this thread and see who explained what the problem is with gets() and who just called it "evil" or "wrong".Quote:
that well why would you want to be using something that will only cause you pain in the end, for an extra line of code you can achieve a higher understanding of C and prepare yourself for the future
Here is the blind truth, I don't care why we have to do it a certain way. If you had a jigsaw skill saw, you don't use your hand to test the blade. Its common sense to lose the gets() (even though I never used it) and the scanf() (my favorite autistic friend) if there are issues. For the record in your quote are you saying that people can't learn another function or a better way?Quote:
If you don't know the problems or the solutions, Salem and friends want you to blindly use fgets() and not bother learning at all.
fgets vs getsQuote:
What does fgets() use or do differently then scanf() and gets().
The basic idea is that with fgets you can specify how many characters you want to read, whereas with gets, you just send a buffer and it will stick everything from stdin into that buffer (even if it goes over the bound). As for scanf, I think Dave_Sinkula had started a thread a while back explaining what was wrong, but essentially you just can't be sure of how scanf will react to incorrect input (Don't quote me on that, it's from memory)
Case in point, through the year and a half (close to 2 years) I've been here, the board here has been commited to providing correct, professional solutions to problems people could have with C. It's not about making one hit wonders. I feel that if people who ask questions here aren't willing to take the time to learn fgets to get input properly, they shouldn't be learning C.
There's been tons of threads of people complaining about "but my teacher says use gets", which is fine. If your teacher tells you to use gets, sure, even if he's wrong, do it. But on the boards here, where things need to be correct no matter what, gets should never be suggested.
I wouldn't even mind if people did this. In every book I've read they teach you gets, but then tell you to never use it. That's like teaching you to drive a car, then taking the car away. If the only easy way to get input in the eyes of the people who write books is through gets and scanf, then maybe they should leave input handling to where it is more appropriate (AKA, not at the beginning.)Quote:
Salem and friends want you to blindly use fgets() and not bother learning at all.
Ok question about fgets(), I wanted to try it out in an old program of mine.
Anyone care to explain what I am doing wrong? Does fgets only work with chars?Code:#include <stdio.h>
int main()
{
unsigned long int x,y;
printf("welcome to the gfc:\n");
fgets(x, sizeof x, stdin);
printf("Second number:\n");
fgets(y,sizeof y, stdin);
}
ok in Dev C++ 4.9.9.2 I get the following errors
invalid conversion from "long unsigned int" to "char"
Everything coming from outside your program is a character stream. Functions like scanf() automatically do formatting and conversions for you, but with unformatted functions like fgets(), you have to use a string and do the formatting and conversions yourself:
Code:#include <stdio.h>
#include <stdlib.h>
int main( void )
{
unsigned long int x, y;
char s[256];
printf( "welcome to the gfc:\n" );
fgets( s, sizeof s, stdin );
x = strtoul( s, NULL, 0 );
printf( "Second number: " );
fgets( s,sizeof s, stdin );
y = strtoul( s, NULL, 0 );
return 0;
}
Quote:
Originally Posted by KoG Metalgod
Did you ever take a look at the function prototype:
Code:char * fgets ( char * str, int num, FILE * stream );
I don't understand why flamers come to boards, its a question and an answer. Thanks Noir for the response.
It wasn't a flame. It was in my opinion, "a question and an answer" all rolled into one. It was a question, asking you if you even bother looking at what the functions you try to use expect for arguments. It was an answer, because if you had, you wouldn't have wasted time posting on the forum when you would have solved it yourself.
Quzah.