I never once claimed that gets is safe. I said it can be used safely. Do you see the difference?
I never once claimed that gets is safe. I said it can be used safely. Do you see the difference?
Yes, I do. If you were responsible for ensuring the space shuttle was safe, you would ensure the nose wheel was fully inflated but forget to ensure the astronauts had breathable air.
I don't think you do since you seem to think I've suggested that gets is inherently safe, when that's basically the kind of perspective I'm arguing against.
Fact is, it works in a predictable way except for two factors (the parameter it receives and the state of stdin). You can't evaluate the safety of gets by ignoring those two factors, you need to take them into account when speaking of safety. By treating it as an individual unit you pretend that those two factors don't matter and that it's automatically 'safe' or 'unsafe', which is obviously stupid. If you can guarantee that the data it reads from stdin will fit into the memory pointed to by its first parameter, then *the call* is safe, otherwise it's liable to break, hence making *the call* unsafe.
Then how about an open challenge? Please, for the audience, programatically determine that gets() is safe. I'm genuinely curious, but I bet whatever you do is more trouble than it's worth.If you can guarantee that the data it reads from stdin will fit into the memory pointed to by its first parameter, then *the call* is safe, otherwise it's liable to break, hence making *the call* unsafe.
I can't accept that.
Even so, the program has the following results.Code:mingw32-gcc.exe -Wall -g -pedantic -Wextra -Wall -ansi -g -c C:\Users\Josh2\Documents\foo\foo.c -o obj\Debug\foo.o C:\Users\Josh2\Documents\foo\foo.c: In function 'main': C:\Users\Josh2\Documents\foo\foo.c:2: warning: control reaches end of non-void function mingw32-g++.exe -o bin\Debug\foo.exe obj\Debug\foo.o Output size is 25.42 KB Process terminated with status 0 (0 minutes, 0 seconds) 0 errors, 1 warnings
Process returned 2686751 (0x28FF1F) execution time : 0.016 s
Press any key to continue.
What on earth are you trying to prove?
That one would be a bad example, though for the claim made, I think it has no flaws (if I understand what is allowed for ungetc correctly). A better example, but it has flaws that Barney McGrew glossed over.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
Your C implementation is clearly broken. Apparently it's a C++ implementation.mingw32-g++.exe
C:\Users\Josh2\Documents\foo\foo.c:2: warning: control reaches end of non-void function
Process returned 2686751 (0x28FF1F) execution time : 0.016 s
Nothing really, I just made a comment and people started responding to it, so I started responding to them. What fun it's been.What on earth are you trying to prove?
edit: But if you want to get a better idea of the topic, my initial post is here: strcpy get errors
Last edited by Barney McGrew; 01-18-2013 at 02:51 AM.
MinGW uses g++ to link C programs, which is not broken. If you read the whole log, it also uses gcc to generate the object code.Your C implementation is clearly broken. Apparently it's a C++ implementation.
Well you are being a bit of a troll. The problem with gets() is well understood. And the only thing you can do is write code with it that no one has any business using.Nothing really, I just made a comment and people started responding to it, so I started responding to them. What fun it's been.
Try building it with -std=c99 or -std=c11 then. Or simply type “return 0;” at the end of main's definition.MinGW uses g++ to link C programs, which is not broken. If you read the whole log, it also uses gcc to generate the object code.
Perhaps. But the invalidity of the common claim “gets is impossible to use safely” isn't.The problem with gets() is well understood.
Last edited by Barney McGrew; 01-18-2013 at 03:02 AM. Reason: fixed cflags
:STry building it with -std=c99 or -std=c11 then. Or simply type “return 0;” at the end of main's definition.
I had the lowly expectation of being able to use gets() to retrieve input. I am not interested in fancy ways of writing skeleton programs. But hey you know, it's good I guess that you're such a stickler for being correct. Try seeing the forest for the trees.
I think that the claim that gets is impossible to use safely is indeed invalid. As I stated in post #49, it is possible to use gets safely, but the responsibility for safe use lies with the user, hence gets cannot be rendered safe by the program, from what I understood at the time.Originally Posted by Barney McGrew
However, you approached this from a different angle where you stated that the program itself can ensure the safe use. In this, sorry, as I noted earlier, I am still not convinced, because the first of your two counter examples is valid but does not demonstrate a reasonable use of gets, whereas the other is invalid because, besides use of a function that apparently results in undefined behaviour, there are reasonable scenarios in which it fails with no recourse (other than not using gets) that you have provided.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
Pfft. That sounds like kid stuff. I use it to write crappy programs that use fseek and stuff.I had the lowly expectation of being able to use gets() to retrieve input.
There aren't any skeletons in my programs.I am not interested in fancy ways of writing skeleton programs.
Why?But hey you know, it's good I guess that you're such a stickler for being correct.
There aren't any forests near where I live, unfortunately.Try seeing the forest for the trees.
I consider that unsafe because it can potentially break, as the input received during interpretation, through stdin, ought to be considered uncontrollable and unpredictable.As I stated in post #49, it is possible to use gets safely, but the responsibility for safe use lies with the user, hence gets cannot be rendered safe by the program, from what I understood at the time.
I suppose you have a different interpretation of the word 'use' then. For me it's 'wherever gets is called', perhaps 'use' might imply 'used for a useful purpose' for you. I dunno.In this, sorry, as I noted earlier, I am still not convinced, because the first of your two counter examples is valid but does not demonstrate a reasonable use of gets
SeeI never suggested you thought that.You have just contradicted your own insistence that a use case which is rarely (*cough* virtually never) used in practice, is significant in claiming that gets() is safe.
Last edited by Barney McGrew; 01-18-2013 at 03:37 AM. Reason: fixed a quote
Yes, it ought to be treated as such. However, in some special cases, it is really is okay... for now.Originally Posted by Barney McGrew
Yes. It should be useful. Otherwise, what's the point? It doesn't help me explain anything practical to a beginner wondering why gets should not be used.Originally Posted by Barney McGrew
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)