From: Keith M. <kei...@us...> - 2006-07-16 07:46:03
|
Felix, If you want private consultations, then my professional fee is seven hundred UK pounds (one thousand and fifty euros) per day; otherwise, please keep all correspondence on the list. On Saturday 15 July 2006 4:25 pm, Felix VIII wrote: > >Please provide a *minimal* test case to demonstrate your problem, > >*including* source code, the *exact* commands you use, and the > >diagnostics on which you base your assertion. > > int main() > { > char a, b[5], c, d; > > printf("Test 1\n"); > scanf("%c", &a); > printf("Test 2\n"); > gets(b); > printf("Test 3\n"); > scanf("%c", &c); > printf("Test 4\n"); > scanf("%c", &d); > printf("End"); > return 0; > } Well, this doesn't illustrate anything, for nowhere do you actually echo back what has beed read. Apart from the missing `#include <stdio.h>', I see only one obvious problem in this, and that's the buffer overrun you cause with the `gets(b)', if the input record exceeds four bytes in length -- indeed, `gets()' is *always* a dangerous function to use, for no matter how big a buffer you provide, there will always be potential for an input record to overrun it, and, if I compile your test case, (using gcc-2.96, on my GNU/Linux box), I see: $ gcc -o testcase testcase.c /tmp/ccyu95Eb.o: In function `main': /tmp/ccyu95Eb.o(.text+0x42): the `gets' function is dangerous and should not be used. > this is a file I used to test it, and I got back: > Test 1 > a > Test 2 > Test 3 > a > Test 4 > End Right, you don't show clearly what is input, and what is output; neither have you shown the commands you used to run your test case, nor any diagnostic comparison, as I requested, between what you expected to see, and the actual output. Based on what I see in your post, I'm guessing at: $ gcc -o testcase testcase.c /tmp/ccyu95Eb.o: In function `main': /tmp/ccyu95Eb.o(.text+0x42): the `gets' function is dangerous and should not be used. $ cat testcase.in a a $ ./testcase < testcase.in Test 1 Test 2 Test 3 Test 4 End which is *exactly* what I would expect to see, from the source you have provided; i.e. correct behaviour, so where's the problem? Regards, Keith. |
From: Daniel K. O. <dan...@ya...> - 2006-07-17 02:57:21
|
Keith Marshall escreveu: > which is *exactly* what I would expect to see, from the source you have > provided; i.e. correct behaviour, so where's the problem? > You forgot to mention that scanf and gets are provided by MS C Runtime, so even if they have a problem, MinGW can't fix them. :) But let me try to be more objective; Felix probably needs to read comp.lang.c FAQ: http://c-faq.com/stdio/scanfinterlace.html http://c-faq.com/stdio/scanfhang.html This is also a good read: http://catb.org/esr/faqs/smart-questions.html#id264997 http://catb.org/esr/faqs/smart-questions.html#before --- Daniel K. O. _______________________________________________________ Você quer respostas para suas perguntas? Ou você sabe muito e quer compartilhar seu conhecimento? Experimente o Yahoo! Respostas ! http://br.answers.yahoo.com/ |
From: Keith M. <kei...@to...> - 2006-07-17 08:48:12
|
Daniel K. O. wrote, quoting me: >> which is *exactly* what I would expect to see, from the source you >> have provided; i.e. correct behaviour, so where's the problem? > > > You forgot to mention that scanf and gets are provided by MS C Runtime, > so even if they have a problem, MinGW can't fix them. :) No, I didn't forget. I simply wasn't going to offer any recommendation concerning a perceived problem, on the basis of a test case which failed to show that there actually was a problem; I hoped that Felix might provide a new test case, to illustrate his real issue, so that I could then offer *relevant* advice. Thanks for the links, though. I can't actually access the last two, as they are blocked by my company's firewall. :-( I do note that the first happily talks about using `gets()', without the slightest hint as to how bad it is; it's almost a *guaranteed* buffer overrun, just waiting to occur at some time, and quite simply should never be used by any serious programmer. Regards, Keith. |
From: Felix V. <alp...@ho...> - 2006-07-17 14:02:55
|
>From: Keith Marshall <kei...@us...> >Reply-To: kei...@us... >To: "Felix VIII" <alp...@ho...> >CC: min...@li... >Subject: Re: [Mingw-users] scanf/gets double-use problem >Date: Sun, 16 Jul 2006 08:49:10 +0100 > >Felix, > > >On Saturday 15 July 2006 4:25 pm, Felix VIII wrote: > > >Please provide a *minimal* test case to demonstrate your problem, > > >*including* source code, the *exact* commands you use, and the > > >diagnostics on which you base your assertion. > > > > int main() > > { > > char a, b[5], c, d; > > > > printf("Test 1\n"); > > scanf("%c", &a); > > printf("Test 2\n"); > > gets(b); > > printf("Test 3\n"); > > scanf("%c", &c); > > printf("Test 4\n"); > > scanf("%c", &d); > > printf("End"); > > return 0; > > } > >Well, this doesn't illustrate anything, for nowhere do you actually echo >back what has beed read. Apart from the missing `#include <stdio.h>', I >see only one obvious problem in this, and that's the buffer overrun you >cause with the `gets(b)', if the input record exceeds four bytes in >length -- indeed, `gets()' is *always* a dangerous function to use, for >no matter how big a buffer you provide, there will always be potential >for an input record to overrun it, and, if I compile your test case, >(using gcc-2.96, on my GNU/Linux box), I see: > > $ gcc -o testcase testcase.c > /tmp/ccyu95Eb.o: In function `main': > /tmp/ccyu95Eb.o(.text+0x42): the `gets' function is dangerous and > should not be used. > > > this is a file I used to test it, and I got back: > > Test 1 > > a > > Test 2 > > Test 3 > > a > > Test 4 > > End > >Right, you don't show clearly what is input, and what is output; neither >have you shown the commands you used to run your test case, nor any >diagnostic comparison, as I requested, between what you expected to see, >and the actual output. Based on what I see in your post, I'm guessing at: > > $ gcc -o testcase testcase.c > /tmp/ccyu95Eb.o: In function `main': > /tmp/ccyu95Eb.o(.text+0x42): the `gets' function is dangerous and > should not be used. > > $ cat testcase.in > a > a > > $ ./testcase < testcase.in > Test 1 > Test 2 > Test 3 > Test 4 > End > >which is *exactly* what I would expect to see, from the source you have >provided; i.e. correct behaviour, so where's the problem? > >Regards, >Keith. I acknowledge I failed to use the line '#include <stdio.h>'. I have tested that as well and it provided the same results. So what you're saying is this is expected behavior from these functions. even though you failed to mention it, the scanf function doesn't work the third time it is used, I'm not sure if that was because I'm not getting the point... _________________________________________________________________ Is your PC infected? Get a FREE online computer virus scan from McAfee® Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 |
From: Keith M. <kei...@to...> - 2006-07-17 14:57:34
|
Felix VII wrote, quoting me: >> $ ./testcase < testcase.in >> Test 1 >> Test 2 >> Test 3 >> Test 4 >> End >> >> which is *exactly* what I would expect to see, from the source you have >> provided; i.e. correct behaviour, so where's the problem? > > I acknowledge I failed to use the line '#include <stdio.h>'. I have > tested that as well and it provided the same results. > > So what you're saying is this is expected behavior from these functions. No. What I am saying is that your test case distills down to: #include <stdio.h> int main() { printf( "Test 1\n" ); printf( "Test 2\n" ); printf( "Test 3\n" ); printf( "Test 4\n" ); printf( "End" ); return 0; } and the output you report is exactly what would be expected from that reduction of your source code. > even though you failed to mention it, the scanf function doesn't work > the third time it is used, ... How can you say that? Your test case does ABSOLUTELY NOTHING to either prove or refute this assertion that scanf doesn't work. Sure, you've interspersed scanf calls amongst the printfs, but, in your test context, they are just irrelevant noise; they have no effect on the outcome of the test. (IOW, your test is irrelevant, because it doesn't test your hypothesis that scanf and gets don't work). > I'm not sure if that was because I'm not getting the point... I think that you are seriously missing the point :-) Regards, Keith. |
From: Alain <mi...@as...> - 2006-07-17 15:27:36
|
------------------------------------------ From/De [Keith MARSHALL] On/Le [2006/07/17 14:53] ------------------------------------------ Felix VII queried the use of scanf and wrote: >> I'm not sure if that was because I'm not getting the point... Keith replied: > I think that you are seriously missing the point :-) Not very helpful methinks <g>. To Felix: scanf 'scans' a string or stream for input (btw it is a bad idea to use scanf, prefer to read a string somehow, then use sscanf) and does something with is based on the format string and pointers to variables that you supplied. No variant of scanf produces any output to stdout. If you want to see the result of a scanf function, you must explicitly output some of the results. n = sscanf(...); Read the manual on scanf for full explanations ('info scanf' may be available on your system, if not dig up the same stuff on the internet or other documentation as may be available to you). Regards, Alain. |
From: Keith M. <kei...@to...> - 2006-07-17 15:43:53
|
Alain wrote: >>> I'm not sure if that was because I'm not getting the point... > > Keith replied: >> I think that you are seriously missing the point :-) > > Not very helpful methinks <g>. No, this was a throw away response to the OP's one liner above. However, the OP had already been pointed to Steve Summit's discussion of scanf() and gets(), which he clearly needs to read: http://c-faq.com/stdio/scanfinterlace.html http://c-faq.com/stdio/scanfhang.html BTW, this cited discussion also misses the opportunity to point out the serious deficiency of gets(), which really is a buffer overrun in the making; (read: `you shouldn't use it, ever'). Regards, Keith. |
From: Alain <mi...@as...> - 2006-07-17 17:04:43
|
------------------------------------------ From/De [Keith MARSHALL] On/Le [2006/07/17 15:43] ------------------------------------------ > Alain wrote: >>>> I'm not sure if that was because I'm not getting the point... >> Keith replied: >>> I think that you are seriously missing the point :-) >> Not very helpful methinks <g>. > > No, this was a throw away response to the OP's one liner above. Me too <g> > However, the OP had already been pointed to Steve Summit's discussion > of scanf() and gets(), which he clearly needs to read: > http://c-faq.com/stdio/scanfinterlace.html > http://c-faq.com/stdio/scanfhang.html > > BTW, this cited discussion also misses the opportunity to point out > the serious deficiency of gets(), which really is a buffer overrun in > the making; (read: `you shouldn't use it, ever'). So what is the alternative you suggest? For simple operations, I'd like to think that getline should do the job. But you seem more expert than I am. Regards, Alain. |
From: Dave K. <dav...@ar...> - 2006-07-17 17:17:26
|
On 17 July 2006 18:04, Alain wrote: > ------------------------------------------ > From/De [Keith MARSHALL] > On/Le [2006/07/17 15:43] > ------------------------------------------ >> BTW, this cited discussion also misses the opportunity to point out >> the serious deficiency of gets(), which really is a buffer overrun in >> the making; (read: `you shouldn't use it, ever'). > > So what is the alternative you suggest? > For simple operations, I'd like to think that getline should do the job. The simplest replacement for gets (...) is fgets (...), using stdin. It's exactly the same in operation, but you get to specify the maximum size of your buffer, and it won't overrun that. cheers, DaveK -- Can't think of a witty .sigline today.... |
From: Keith M. <kei...@us...> - 2006-07-18 18:54:59
|
On Monday 17 July 2006 6:04 pm, Alain wrote: > > However, the OP had already been pointed to Steve Summit's discussion > > of scanf() and gets(), which he clearly needs to read: > > http://c-faq.com/stdio/scanfinterlace.html > > http://c-faq.com/stdio/scanfhang.html > > > > BTW, this cited discussion also misses the opportunity to point out > > the serious deficiency of gets(), which really is a buffer overrun in > > the making; (read: `you shouldn't use it, ever'). > > So what is the alternative you suggest? As suggested by others, and as recommended by POSIX `fgets()' is the simplest alternative: http://www.opengroup.org/onlinepubs/009695399/functions/gets.html http://www.opengroup.org/onlinepubs/009695399/functions/fgets.html Actually, while `fgets()' is safe from buffer overruns, it doesn't guarantee to get a full line from the input stream; the input will be curtailed, if the buffer you provide isn't big enough. Often, depending on the application, I will either use low level `read()' calls, to load my own buffer, then parse the input there, or I will use `getchar()' for stdin, or `fgets()' for other streams, in a loop, to assemble the input into my own buffer, which I can `grow' as required, to implement a `getline()' function. > For simple operations, I'd like to think that getline should do the > job. I would never rely on a system supplied `getline()' function; it isn't specified by POSIX, so may not exist on all platforms you want to target. If you use it, be prepared to provide your own implementation -- in fact, provide your own implementation anyway; you can make it so much more flexible and generally useful than M$'s version, (e.g. you can use a `growable' buffer, as I suggested above). Regards, Keith. |
From: Keith M. <kei...@to...> - 2006-07-19 09:02:04
|
I wrote, quoting Alain: >> For simple operations, I'd like to think that getline should do the >> job. > > I would never rely on a system supplied `getline()' function; it isn't > specified by POSIX, so may not exist on all platforms you want to target. > If you use it, be prepared to provide your own implementation -- in fact, > provide your own implementation anyway; you can make it so much more > flexible and generally useful than M$'s version, (e.g. you can use a > `growable' buffer, as I suggested above). Hmm. Looking more closely at MSDN, it seems that even M$ don't provide a `getline()' function for `C'; there are `getline' methods for various `C++' classes, which *should* be portable, but there's no `C' function of this name. The GNU `C' library does provide a `getline' function for `C': http://www.gnu.org/software/libc/manual/html_node/Line-Input.html However, this is non-standard, and if you are targetting platforms which lack GNU's `libc', then you are still going to have to provide your own implementation, or find an alternative library which provides it. I tend to favour providing my own implementation; that lets me customise it, to suit my own needs, on a per-application basis. Regards, Keith. |
From: Daniel K. O. <dan...@ya...> - 2006-07-17 23:58:03
|
Keith MARSHALL escreveu: > http://c-faq.com/stdio/scanfinterlace.html > http://c-faq.com/stdio/scanfhang.html > > BTW, this cited discussion also misses the opportunity to point out > the serious deficiency of gets(), which really is a buffer overrun in > the making; (read: `you shouldn't use it, ever'). > Actually, it doesn't miss the point. The "see also" link "12.23" at the bottom, points the reader to a discussion about how using gets() is a bad idea. --- Daniel K. O. _______________________________________________________ Novidade no Yahoo! Mail: receba alertas de novas mensagens no seu celular. Registre seu aparelho agora! http://br.mobile.yahoo.com/mailalertas/ |
From: Keith M. <kei...@to...> - 2006-07-18 09:41:26
|
Daniel K. O. wrote, quoting me: >> http://c-faq.com/stdio/scanfinterlace.html >> http://c-faq.com/stdio/scanfhang.html >> >> BTW, this cited discussion also misses the opportunity to point out >> the serious deficiency of gets(), which really is a buffer overrun in >> the making; (read: `you shouldn't use it, ever'). > > Actually, it doesn't miss the point. The "see also" link "12.23" at the > bottom, points the reader to a discussion about how using gets() is a > bad idea. Ok, yes it does. The problem is, that `see also' link is *much* too easy to overlook, especially since there's no indication of what it relates to; (it's an answer to some other, unspecified question). On reading the original answer: a) I felt that the original question had been adequately answered, so why would I bother to look further? b) I did notice a `longer explanation' link, which I followed. That made a vague allusion to `gets' maybe being a bad idea, but didn't offer any further explanation as to why not. c) Once I've followed that `longer explanation' link, I've lost the `see also' links on the original page, so it has become very much `out of sight; out of mind'. Nope. IMO, it does `miss the opportunity', simply because it doesn't draw sufficient attention to the potential problem, in the first place. Much better, I would say, to *explicitly* state, right there in the answer to Q.12.18a, that you should avoid using `gets', and point to Q.12.23 for the explanation as to `why not', rather that simply adding the reference as an unqualified, throw away `see also'. Regards, Keith. |
From: Felix V. <alp...@ho...> - 2006-07-17 15:56:53
|
>From: Alain <mi...@as...> >Reply-To: MinGW Users List <min...@li...> >To: MinGW Users List <min...@li...> >Subject: Re: [Mingw-users] scanf/gets double-use problem >Date: Mon, 17 Jul 2006 15:27:16 +0000 > >------------------------------------------ >From/De [Keith MARSHALL] >On/Le [2006/07/17 14:53] >------------------------------------------ >Felix VII queried the use of scanf and wrote: > > >> I'm not sure if that was because I'm not getting the point... > >Keith replied: > > I think that you are seriously missing the point :-) > >Not very helpful methinks <g>. > >To Felix: >scanf 'scans' a string or stream for input (btw it is a bad idea to use >scanf, prefer to read a string somehow, then use sscanf) and does >something with is based on the format string and pointers to variables >that you supplied. No variant of scanf produces any output to stdout. > >If you want to see the result of a scanf function, you must explicitly >output some of the results. > >n = sscanf(...); > >Read the manual on scanf for full explanations ('info scanf' may be >available on your system, if not dig up the same stuff on the internet >or other documentation as may be available to you). > >Regards, >Alain. > > >------------------------------------------------------------------------- >Using Tomcat but need to do more? Need to support web services, security? >Get stuff done quickly with pre-integrated technology to make your job >easier >Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo >http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 >_______________________________________________ >MinGW-users mailing list >Min...@li... > >You may change your MinGW Account Options or unsubscribe at: >https://lists.sourceforge.net/lists/listinfo/mingw-users thank you, not exactly sure what most of that meant but thx neway... _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ |
From: Felix V. <alp...@ho...> - 2006-07-17 16:00:42
|
>From: Keith MARSHALL <kei...@to...> >Reply-To: Keith MARSHALL <kei...@to...>,MinGW Users List ><min...@li...> >To: MinGW Users List <min...@li...> >Subject: Re: [Mingw-users] scanf/gets double-use problem >Date: Mon, 17 Jul 2006 15:53:31 +0100 > >Felix VII wrote, quoting me: > >> $ ./testcase < testcase.in > >> Test 1 > >> Test 2 > >> Test 3 > >> Test 4 > >> End > >> > >> which is *exactly* what I would expect to see, from the source you have > >> provided; i.e. correct behaviour, so where's the problem? > > > > I acknowledge I failed to use the line '#include <stdio.h>'. I have > > tested that as well and it provided the same results. > > > > So what you're saying is this is expected behavior from these functions. > >No. What I am saying is that your test case distills down to: > > #include <stdio.h> > > int main() > { > printf( "Test 1\n" ); > printf( "Test 2\n" ); > printf( "Test 3\n" ); > printf( "Test 4\n" ); > printf( "End" ); > return 0; > } > >and the output you report is exactly what would be expected from that >reduction of your source code. > > > even though you failed to mention it, the scanf function doesn't work > > the third time it is used, ... > >How can you say that? Your test case does ABSOLUTELY NOTHING to either >prove or refute this assertion that scanf doesn't work. Sure, you've >interspersed scanf calls amongst the printfs, but, in your test context, >they are just irrelevant noise; they have no effect on the outcome of >the test. (IOW, your test is irrelevant, because it doesn't test your >hypothesis that scanf and gets don't work). > > > I'm not sure if that was because I'm not getting the point... > >I think that you are seriously missing the point :-) > >Regards, >Keith. > > ... um... I'm sorry? >------------------------------------------------------------------------- >Using Tomcat but need to do more? Need to support web services, security? >Get stuff done quickly with pre-integrated technology to make your job >easier >Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo >http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 >_______________________________________________ >MinGW-users mailing list >Min...@li... > >You may change your MinGW Account Options or unsubscribe at: >https://lists.sourceforge.net/lists/listinfo/mingw-users _________________________________________________________________ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ |
From: Shawn A. <Sha...@te...> - 2006-07-17 16:16:12
|
Felix VIII wrote: >> Keith MARSHALL wrote: >> >> How can you say that? Your test case does ABSOLUTELY NOTHING to either >> prove or refute this assertion that scanf doesn't work... >> >> > I'm not sure if that was because I'm not getting the point... >> >> I think that you are seriously missing the point :-) >> >> > ... um... I'm sorry? > I think everyone on the list is trying to figure out what is is about scanf() that "doesn't work". Your example does not exploit any functional problems, and you failed to mention in your original post what the problem was! How about stating exactly what problem you have encountered with scanf(), and providing an example that compiles, runs, and displays said problem. I'm sure the problem could be solved quickly if you provided this! -- Shawn Authement, Software Engineer Texas Memory Systems, Inc. (http://www.superssd.com) ph: 713.266.3200 |
From: Alain <mi...@as...> - 2006-07-17 17:18:57
|
------------------------------------------ From/De [Shawn Authement] On/Le [2006/07/17 16:16] ------------------------------------------ > Felix VIII wrote: >>> Keith MARSHALL wrote: >>> >>> How can you say that? Your test case does ABSOLUTELY NOTHING to either >>> prove or refute this assertion that scanf doesn't work... >>> >>>> I'm not sure if that was because I'm not getting the point... >>> I think that you are seriously missing the point :-) >>> >>> >> ... um... I'm sorry? >> > I think everyone on the list is trying to figure out what is is about > scanf() that "doesn't work". Your example does not exploit any > functional problems, and you failed to mention in your original post > what the problem was! > > How about stating exactly what problem you have encountered with > scanf(), and providing an example that compiles, runs, and displays said > problem. I'm sure the problem could be solved quickly if you provided this! Shawn, I think this will not help Felix as he seems to not understand that scanf does not produce any output and did not understand my, admittedly half attempt to explain exactly this. Felix, you need to: 1/ read the standard input (maybe using something like getline, read the manual for details), this will put the line read into a buffer or string; 2/ use sscanf (note the two s') on that string to extract into variables what you want to read, e.g. n=sscanf(input_line, "%c", &input_character). n will show you how many items of the format string have been scanned successfully and placed into your variables - this is useful as it tells you whether sscanf worked as you expected or not; 3/ if you want to see the results of sscanf on the output, then you must use some printf statements that show what you want to show, e.g. n, input_character or whatever else you might have used in your sscanf statements. Once you understand those principles, then read the links posted by all those who try to help you and re-read the documentation for each command. Regards, Alain. |
From: Shawn A. <Sha...@te...> - 2006-07-17 18:32:51
|
Alain wrote: > Shawn, I think this will not help Felix as he seems to not understand > that scanf does not produce any output... > Good point. I think I was reading too much into the verbage used to describe the issue in the original post: > "...scanf() and gets() both do not work on the second time (even if > scanf and then gets is used)..." (i.e. "...the second time...") But, in re-reading the following posts, I see the failure to determine what the functions actually did by printing the output of what they scanned in! -- Shawn Authement, Software Engineer Texas Memory Systems, Inc. (http://www.superssd.com) ph: 713.266.3200 |
From: Felix V. <alp...@ho...> - 2006-07-17 20:32:11
|
basically my problem is that I'm trying to figure out why both scanf and gets will not let you input ANYTHING (skips right over the function) EVERY OTHER TIME either is used.... otherwise never mind _________________________________________________________________ On the road to retirement? Check out MSN Life Events for advice on how to get there! http://lifeevents.msn.com/category.aspx?cid=Retirement |
From: Alain <mi...@as...> - 2006-07-17 21:34:57
|
------------------------------------------ From/De [Felix VIII] On/Le [2006/07/17 20:32] ------------------------------------------ > basically my problem is that I'm trying to figure out why both scanf and > gets will not let you input ANYTHING (skips right over the function) EVERY > OTHER TIME either is used.... otherwise never mind The purpose of scanf is not to read from stdin. Read the documentation and you'll see that its use can be unpredictable if attempting to read from a stream as opposed to a string. Get your information in (fgets), then use sscanf to interpret the data and store the relevant values in your variables. If all you want is input character by character then use fgetc, if you prefer to read line by line, then use fgets. Personally when dealing with stdin, I prefer to use fgetc because it gives you greater control over how you read the input, but maybe you don't need to worry about that sort of thing at this point. Regards, Alain. |
From: Felix V. <alp...@ho...> - 2006-07-17 21:39:31
|
>From: Alain <mi...@as...> >Reply-To: MinGW Users List <min...@li...> >To: MinGW Users List <min...@li...> >Subject: Re: [Mingw-users] scanf/gets double-use problem >Date: Mon, 17 Jul 2006 21:34:46 +0000 > >------------------------------------------ >From/De [Felix VIII] >On/Le [2006/07/17 20:32] >------------------------------------------ > > basically my problem is that I'm trying to figure out why both scanf and > > gets will not let you input ANYTHING (skips right over the function) >EVERY > > OTHER TIME either is used.... otherwise never mind > >The purpose of scanf is not to read from stdin. Read the documentation >and you'll see that its use can be unpredictable if attempting to read >from a stream as opposed to a string. >Get your information in (fgets), then use sscanf to interpret the data >and store the relevant values in your variables. > >If all you want is input character by character then use fgetc, if you >prefer to read line by line, then use fgets. > >Personally when dealing with stdin, I prefer to use fgetc because it >gives you greater control over how you read the input, but maybe you >don't need to worry about that sort of thing at this point. > >Regards, >Alain. thanks, and btw I apologize for any confusion or irritation I may have caused earlier. _________________________________________________________________ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ |
From: L. D. <cod...@ho...> - 2006-07-18 01:16:18
|
----- Original Message ----- From: "Felix VIII" <alp...@ho...> To: <min...@li...> Sent: Tuesday, July 18, 2006 4:32 AM Subject: Re: [Mingw-users] scanf/gets double-use problem > basically my problem is that I'm trying to figure out why both scanf and > gets will not let you input ANYTHING (skips right over the function) EVERY > OTHER TIME either is used.... otherwise never mind In case you still didn't learn more about scanf(), the simplest explanation is that your first call to scanf() returned the character you typed and the second call to scanf() returned the newline character that you typed by pressing Enter. Luke |
From: Keith M. <kei...@to...> - 2006-07-17 17:05:00
|
Felix VIII wrote, quoting me: >> How can you say that? Your test case does ABSOLUTELY NOTHING to either >> prove or refute this assertion that scanf doesn't work. Sure, you've >> interspersed scanf calls amongst the printfs, but, in your test context, >> they are just irrelevant noise; they have no effect on the outcome of >> the test. (IOW, your test is irrelevant, because it doesn't test your >> hypothesis that scanf and gets don't work). >> >>> I'm not sure if that was because I'm not getting the point... > >> I think that you are seriously missing the point :-) > > ... um... I'm sorry? Ok. You clearly don't understand what scanf is supposed to do; you need to invest in a good book on C programming. Your test case fails to meet its objective, because it doesn't show what the effect of any of the scanf calls is; all it actually tests is that printf can print a constant string. As Alain has pointed out, you need to actually include the variables you loaded, with your calls to scanf, in at least one of your printf statements, so you can see the effect. And, as I've hinted previously, you should never use gets(); it's much too likely to scribble over memory it has no business touching. Regards, Keith. |