And no, if something allows errors to happen it doesn't work.
Hey, if it works sometimes, it works. That's just a simple, logical fact.
My car works. If it doesn't start the first time, it does not mean that it doesn't work. It just means that it did not work that time.
If it doesn't work sometimes, it does not work sometimes.
You exist. Errors happen.
Do you work?
Hey, if it works sometimes, it works. That's just a simple, logical fact.
Au contraire. If it only sometimes works, it's broken.
Do you work? If so,would you accept a $100 drop in pay this week because the payroll program only makes a mistake once in a while and doesn't add your hours correctly? After all, it is only once in 3 months...
Close enough doesn't work in computers.
Au contraire. If it only sometimes works, it's broken.
Do you work? If so,would you accept a $100 drop in pay this week because the payroll program only makes a mistake once in a while and doesn't add your hours correctly? After all, it is only once in 3 months...
Close enough doesn't work in computers.
Definition: works
It does the job.
Is it acceptable to WaltP?
I really don't care.
gets is still in the documentation. It works.
no, it does not work. arbitrarily writing over chunks of runtime memory is NOT how we define "works"
I wouldn't go so far as to say that it's wrong.
okay, then: it's absolutely wrong.
I would say that it's not safe, not recommended, not the best way to do things.
you're almost right: it's not safe, it's not recommended, and it's the worst way to do "things"
yet, you not only recommended it, but you continue to defend it without pause.
look, we all were prepared to give you benefit of the doubt and chalk it up to an over-eagerness to help. but rather than take a hint, and do some basic research, you now force us to reconsider that you might just be an blooming idiot.
but don't take my word for it. Ask the GNU documentation. Ask the Linux man page. Ask the venerable comp.lang.c FAQ.
Warning: The gets function is very dangerous because it provides no protection against overflowing the string s. The GNU library includes it for compatibility only. You should always use fgets or getline instead. To remind you of this, the linker (if using GNU ld) will issue a warning whenever you use gets. [Bolded terms from original document.]
Never use gets(). Because it is impossible to tell without knowing the data in advance how many characters gets() will read, and because gets() will continue to store characters past the end of the buffer, it is extremely dangerous to use. It has been used to break computer security. Use fgets() instead.
Q: Why does everyone say not to use gets()?
A: Unlike fgets(), gets() cannot be told the size of the buffer it's to read into, so it cannot be prevented from overflowing that buffer if an input line is longer than expected--and Murphy's Law says that, sooner or later, a larger-than-expected input line will occur. (It's possible to convince yourself that, for some reason or another, input lines longer than some maximum are impossible, but it's also possible to be mistaken, and in any case it's just as easy to use fgets.)
.
Good grief!
There was a time when fgets did not exist.
And people said, "gets works."
Now, the more enlightened say it doesn't.
It works under certain conditions. It does not work under other conditions.
Is it safe?
Well, as long as there are hackers out there who have nothing better to do than to break the 1's and 0's of a novice programmer, then there might be a small percentage of instances in the life of gets where gets does not work.
Other than that, I just don't get your logic.
There was a time when fgets did not exist. And people said, "gets works."
no, they said: "use getline()"
It works under certain conditions. It does not work under other conditions.
and those conditions are entirely impossible for the programmer to control. how much more broken does a randomly-exploding function have to be????
Well, as long as there are hackers [minimize, weasel, misdirect].
throw all the red herrings you want, but every computer security expert in the world understands the risk of buffer overflows, and recognizes broken functions like "gets" are the root cause. at the very least it can catastrophically crash the program without any warning. now stop suggesting that people use it, and stop pretending you know better than than the combined experience in the entire body of C programming literature.
look, just bow on out, and go back to BASIC. You seemed to do fairly well over there, and it's become painfully obvious that compiled languages are not your forte.
we've got enough problems to fix. new users break their code and come here for help. not to have it broken some more by someone they assume knows what they're talking about.
.
>>There was a time when fgets did not exist.
There was a time when there were no computers either. So what? what does that prove? AFAIK fgets() was part of the original C standards.
I'm amazed that the Standards for C, have not required that gets() only allow the number of char's that will fit into the destination array, as a default.
How many programs would that break? Seems like if your program was overflowing the buffer array, then you'd WANT to fix it.
I like gets() because it's just more concise, and leaves the newline off, but in it's current form, it's too stupid to be useful.
This is a CG (Computer Graphics) Problem. You have no idea about the C or C++. so, I can't give you suggestion, sorry. CG code's is very hard and you have not understang it.
#include<iostream.h>
#include<conio.h>
#include<graphics.h>
#include<dos.h>
void main()
{
int gd=0,gm;
int x,y,x1,y1,r;
initgraph(&gd,&gm,"c:\\tc\\bgi");
cleardevice();
cout<<"Enter the Starting x:--";
cin>>x;
// same as y,x1,y1and r
rectangle(x,y,x1,y1); // SQUARE
circle(x,y,r); // CIRCLE
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.