Community
Participate
Working Groups
I tried using Eclipse C/C++ (CDT with cygwin) to compile and execute a simple ANSI C program with ’scanf()’ and ‘printf()’ routines. It turns out that some unexpected results happens in the Eclipse Console, when in fact, the same program runs smoothly under “cygwin” X-Term after being compiled with gcc. Here is the simple C program I tried, after creating a “Managed Make C Project”: #include int main() { int integer1, integer2, sum; printf(”Enter first integer:\n”); scanf(”%d”, &integer1); printf(”Enter second integer:\n”); scanf(”%d”, &integer2); sum = integer1 + integer2; printf(”Sum is %d\n”, sum); return 0; } The behaviour in the Console is that no “printf()” statements ever executed until after all the “scanf()” have been executed. Namely, I need to first type in the two integers before the “printf()” messages become visible and the sum is printed. This is certainly not the man-machine interaction intended in the program. My question is this: Is the Eclipse C/C++ (or Eclipse’s CDT build or core itself) programmed to handle the ANSI C’s basic input and output routines such ’scanf()’ and ‘printf()’ properly? For other ANSI C programs using only printf(), I observed that everything seems running smoothly.
The same happens to me using Eclipse 3.3.1.1 with CDT 4.0.1 in combination with MinGW on Windows XP.
I'm 90% sure that the bug is located in console output. It didn't flushes stdout even after ending string with "\n". If i use fflush(stduot) after each printf explicitly everythings works fine, but it's very unconfortable , especially while i compile and run the same simple, "school" program on multiple PC, and almost everywhere Console work fine. Second helpful information could be info, that brogram built with CDT works fine under standard Windows XP cmd.exe, it behave strange ONLY in eclipse console.
Same problem for me using: - eclipse Platform 3.3.2, Build id: M20080221-1800 ; - CDT feature Version: 4.0.3.200802251018, Build id: 200802251018 ; - WinXP - MinGW. You might find useful informations in bugs 106298, 184582, 199219, 228444. Reading these, it appears to me that there is indeed a bug in stdout eclipse console: it does not flush even when printf ends with \n. According to Jordan Rhee (in bug 184582), this behavior is not ANSI-compliant. I didn't verify this. He proposes to use "setvbuf(stdout, NULL, 0, _IONBF);", which is a great workaround for me. According to Doug Schaefer (in bug 199219), "The root cause of the I/O problem is that we're using Windows pipes to communicate with the underlying process. The pipes are buffered and I haven't found a way to do them unbuffered. So you don't see your text until the buffer is full or the flush() routine is called. For input, the Console does capture the text and send it to the process when you hit a new-line." And also: "If you want to respond to key presses, then you should be writing a proper Windows application [AFAIU: with a GUI]. There aren't too many console applications for Windows where the keyboard handling is archaic [AFAIU: isn't archaic]." I'm not sure that this point of view is the best that eclipse team can have. It appears to me that every developer in the world is using (some more than others, and experimented ones, probably far less than beginners) stdout and stdin, esp. when developing little / tests / newbies programs. You even learn that in school! Let us even (temporarily) admit that using the console in Windows C / C++ programming is a bad thing(tm). That does not imply that eclipse should not support this practice. It is a bit hard to not support the practice of many developers in the world (including, and esp., newbies) simply because it is a bad practice... That's why I think that this bug must be brought some attention to! (Although I know very well that the community can't solve every problem in the world in a few days.) I hope many people will vote for it...
Caution: the workaround is rather setvbuf(stdout, NULL, _IONBF, 0); (see MSCN). I had strange behavior with the other version.
Same happened to me! It's very annoying since I'm learning programming and I'm using printf and scanf function all the time. I have Eclipse 3.3.2; MinGW 5.1.4; MSYS 1.0.10. Thanks!
Just a side note, this also occurs with puts(). Putting fflush(stdout) after each instance does work around the problem. Where is the buffering for stdin/stdout handled in Eclipse CDT? A long time ago when I was taking a C class, they talked a little bit about this behavior, resulting on the need for the fflush. Is it possible this is just an unfortunate behavior of C in general?
Hi, See above : "According to Jordan Rhee (in bug 184582), this behavior is not ANSI-compliant. I didn't verify this." Please also read the similar bugs I referenced here above. You will find some technical explanations. Somebody really should close some of these bugs, there is plenty of redundancy among these. Unfortunately, they are not exact duplicates so I don't know which should be closed or have the title re-phrased and which should be kept. They also each have some interesting informations not found in the others! What a mess...
(In reply to comment #7) > See above : "According to Jordan Rhee (in bug 184582), this behavior is not > ANSI-compliant. I didn't verify this." This is not correct. Jordan Rhee wrote in bug 184582 comment 1: "This is inconvenient but correct behavior per ansi c." I try to sum up my understanding of the problem: CDT or Eclipse does not buffer stdout itself. Otherwise the workaround with setvbuf(stdout, NULL, _IONBF, 0) would not work. The default buffer mode of stdout depends on whether it is connected to a terminal or not. If it is connected to a file or pipe, or anything other than a terminal, it is fully buffered. Only if it is connected to a terminal, the default buffer mode is line buffered. This is the mode we are used to when we interact with a program on the command line. And this is what people expect when they try to do the same in the Eclipse console. The problem is: The eclipse console is not a terminal. On unix systems, the method of choice is to create a pseudo terminal (pty) and connect the child process stdio to it. This way the child process behaves exactly in the same way as in an interactive terminal. CDT does exactly that for Linux, Mac OS X, Solaris and some other supported platforms. We don't have a Pty (or something of that kind) on Windows, therefore interactive console mode programs don't work as expected. If someone out there can provide a Pty for Windows, you are more than welcome!
(In reply to comment #8) > (In reply to comment #7) > > See above : "According to Jordan Rhee (in bug 184582), this behavior is not > > ANSI-compliant. I didn't verify this." > > This is not correct. Jordan Rhee wrote in bug 184582 comment 1: "This is > inconvenient but correct behavior per ansi c." In fact it was incomplete. I should have precised that eclipse behavior is not using correct ANSI behavior if I consider Jordan Rhee's definition (which I have not verified the correctness of): << stdout is buffered, which is why your text isn't showing up until your program terminates. stderr is not buffered, so text written to stderr should show up immediately. There are several conditions that will cause the buffer to flush: - newline encountered: printf("blah"); will not immediately show up to stdout, but printf("blah\n"); will. (snip) >> and knowing that eclipse does not flush the buffer when printing "blah\n" (which I verified, and something that Jordan apparently missed). Considering your explanation of eclipse console behavior, I am not an expert, but I wonder how, if that explanation is correct, does the other C++ development environments running on Windows to make their console behave correctly? From a user point of view, eclipse console should behave like a terminal. It is indeed used like a terminal (print statements, get inputs).
(In reply to comment #9) > and knowing that eclipse does not flush the buffer when printing "blah\n" > (which I verified, and something that Jordan apparently missed). Eclipse has no way of flushing a buffer it does not control. Flushing on "\n" would indicate line buffering mode, which is currently not possible on Windows as I tried to explain. > Considering your explanation of eclipse console behavior, I am not an expert, > but I wonder how, if that explanation is correct, does the other C++ > development environments running on Windows to make their console behave > correctly? I guess this question is rhetorical. > From a user point of view, eclipse console should behave like a terminal. It is > indeed used like a terminal (print statements, get inputs). > Agreed.
(In reply to comment #10) > > Considering your explanation of eclipse console behavior, I am not an expert, > > but I wonder how, if that explanation is correct, does the other C++ > > development environments running on Windows to make their console behave > > correctly? > > I guess this question is rhetorical. I am not sure that I understand the word "rhetorical" (I am not a native English speaker). Do you mean that it is not related to the point? Sorry if it is obvious, but how can we say that something is not possible on Windows while other softwares also running on Windows are able to provide the functionality? Would it not be a good idea to think about how others solved the problem we are facing here? Doing a "printf("Hello, world\n")" in MS Visual Studio will make the statement immediately appear on the console. How do they do that, why are they not under the same "no pty in windows" constraint?
(In reply to comment #11) > (In reply to comment #10) > > > Considering your explanation of eclipse console behavior, I am not an expert, > > > but I wonder how, if that explanation is correct, does the other C++ > > > development environments running on Windows to make their console behave > > > correctly? > > > > I guess this question is rhetorical. > > I am not sure that I understand the word "rhetorical" (I am not a native > English speaker). I am not a native English speaker, either. With "rhetorical" I meant, you probably don't expect an answer. > Do you mean that it is not related to the point? Sorry if it > is obvious, but how can we say that something is not possible on Windows while > other softwares also running on Windows are able to provide the functionality? > Would it not be a good idea to think about how others solved the problem we are > facing here? > > Doing a "printf("Hello, world\n")" in MS Visual Studio will make the statement > immediately appear on the console. How do they do that, why are they not under > the same "no pty in windows" constraint? > I did not mean to say it is completely impossible, but rather, it is not supported with current versions of Eclipse/CDT and we would be glad to get support from the community.
I posted the following text to the CDT newsgroup and was pointed to this bug. So I also consider it a fairly big problem for CDT. The problem is that a beginner will try some scanf and printf things and get halted. I do not think they will find the solution in 8 out of 10 instances. I was lucky when googling for it. ============ I am using Eclipse CDT with the MinGW compiler on Windows XP. When I have a program like this #include <stdio.h> #include <stdlib.h> int main(void) { int age; printf("How old are you? "); scanf("%d", &age); printf("\nYou are %d years.", age); return EXIT_SUCCESS; } I get the output: 30 How old are you? You are 30 years. Ie. I have to enter the scanf input before seeing the first printf. If I put in a fflush(stdout) statement like this #include <stdio.h> #include <stdlib.h> int main(void) { int age; printf("How old are you? "); fflush(stdout); scanf("%d", &age); printf("\nYou are %d years.", age); return EXIT_SUCCESS; } I get this output: How old are you? 30 You are 30 years. Which is what I want. My question is if there is a way to avoid using fflush such that the concole in Eclipse CDT behaves like a CMD console in Win XP. That console produces the same output as above without using a fflush statement. The reason for the question is that the IDE (in this case Eclipse CDT) should not make one write different code that one would have done without the IDE.
*** Bug 250369 has been marked as a duplicate of this bug. ***
i think it is a bug. THE CONSOLE DONOT WORK WELL. THE STEPS ARE NOT OUR NEEDS.
If somebody knows how to make windows process behave like it has a terminal please post it here and we may fix windows launcher to include this flag. Otherwise we cannot do anything, see comment #8 which I think has complete explanation of the current state.
I am repeating the workaround mentioned in comment 4: setvbuf(stdout, NULL, _IONBF, 0); Put this as first statement in your main() function. This disables buffering of stdout. I just tried it and it works. A good summary of the problem can also be found here: http://homepages.tesco.net/J.deBoynePollard/FGA/capture-console-win32.html
Comment #18 From Anton Leherbauer 2008 You mean we must use it in our main() function as a programmer? So, i donot think it is right as a programmer. It is not convenien ,if the graft codes use in other platform.
Now the same as eclipse-cpp-ganymede-SR2-win32.zip. The executed order is wrong .
There is no intension (and no possibility) to fix it in CDT, see workarounds
(In reply to comment #21) > There is no intension (and no possibility) to fix it in CDT, see workarounds workarounds ? What is it?
(In reply to comment #21) > There is no intension (and no possibility) to fix it in CDT, see workarounds I would phrase it slightly differently. We are open to suggestions on how this problem can be fixed, but until somebody comes up with a workable idea, the console behavior will remain as it is today.
(In reply to comment #23) > (In reply to comment #21) > > There is no intension (and no possibility) to fix it in CDT, see workarounds > > I would phrase it slightly differently. We are open to suggestions on how this > problem can be fixed, but until somebody comes up with a workable idea, the > console behavior will remain as it is today. > I recently taught a C programming class. I did not know about this bug for some weeks (how should I?), and it was only luck that I found the workaround. So if the concensus is that it can't be fixed, then I suggest to insert a checkbok in the "New C project" wizard that are checked by default and which has the task of disabling buffering. Something that somehow inserts this line in the code: setvbuf(stdout, NULL, _IONBF, 0) if the user wants it. Otherwise, I am close to stating that Eclipse CDT is useless for introductionary C programming. The problem I ran into was that the printf statements did not show the text needed to explain to the user (student) what input the scanf statements was waiting for. Like printf ("What is your name... scanf(.... and we would not see the "What is your name". That is pretty hard to state to the students that CDT was the right choice over say Visual Studio. It is not a critique at all, but it is only arguments for taking this into account in a workaround that could be used in the new C projects wizard. Would the correct CDT person care to say a few words about this idea? /Rasmus
(In reply to comment #24) > (In reply to comment #23) > > (In reply to comment #21) > > > There is no intension (and no possibility) to fix it in CDT, see workarounds > > > > I would phrase it slightly differently. We are open to suggestions on how this > > problem can be fixed, but until somebody comes up with a workable idea, the > > console behavior will remain as it is today. > > > I recently taught a C programming class. I did not know about this bug for some > weeks (how should I?), and it was only luck that I found the workaround. > So if the concensus is that it can't be fixed, then I suggest to insert a > checkbok in the "New C project" wizard that are checked by default and which > has the task of disabling buffering. Something that somehow inserts this line > in the code: > setvbuf(stdout, NULL, _IONBF, 0) > if the user wants it. > Otherwise, I am close to stating that Eclipse CDT is useless for > introductionary C programming. The problem I ran into was that the printf > statements did not show the text needed to explain to the user (student) what > input the scanf statements was waiting for. Like > printf ("What is your name... > scanf(.... > and we would not see the "What is your name". That is pretty hard to state to > the students that CDT was the right choice over say Visual Studio. > It is not a critique at all, but it is only arguments for taking this into > account in a workaround that could be used in the new C projects wizard. > Would the correct CDT person care to say a few words about this idea? > /Rasmus Not that you don't have a point, but at the same time I don't think it's the end of the world to teach students about stream buffering and tell them to use fflush() either. The problem of printf() not always printing immediately due to stream buffering is one that predates Eclipse and CDT. It was a problem when I was in university, which after a two minute discussion on the topic, everyone knew to deal with.
(In reply to comment #25) > (In reply to comment #24) > > (In reply to comment #23) > > > (In reply to comment #21) > > > > There is no intension (and no possibility) to fix it in CDT, see workarounds > > > > > > I would phrase it slightly differently. We are open to suggestions on how this > > > problem can be fixed, but until somebody comes up with a workable idea, the > > > console behavior will remain as it is today. > > > > > I recently taught a C programming class. I did not know about this bug for some > > weeks (how should I?), and it was only luck that I found the workaround. > > So if the concensus is that it can't be fixed, then I suggest to insert a > > checkbok in the "New C project" wizard that are checked by default and which > > has the task of disabling buffering. Something that somehow inserts this line > > in the code: > > setvbuf(stdout, NULL, _IONBF, 0) > > if the user wants it. > > Otherwise, I am close to stating that Eclipse CDT is useless for > > introductionary C programming. The problem I ran into was that the printf > > statements did not show the text needed to explain to the user (student) what > > input the scanf statements was waiting for. Like > > printf ("What is your name... > > scanf(.... > > and we would not see the "What is your name". That is pretty hard to state to > > the students that CDT was the right choice over say Visual Studio. > > It is not a critique at all, but it is only arguments for taking this into > > account in a workaround that could be used in the new C projects wizard. > > Would the correct CDT person care to say a few words about this idea? > > /Rasmus > > Not that you don't have a point, but at the same time I don't think it's the > end of the world to teach students about stream buffering and tell them to use > fflush() either. The problem of printf() not always printing immediately due > to stream buffering is one that predates Eclipse and CDT. It was a problem > when I was in university, which after a two minute discussion on the topic, > everyone knew to deal with. > Actually, I think it is the end of the world. Yes, I found out, but how many teachers or C-programmers figure out this "special behaviour"? My guess is that it is 1 in 50 who stumble over the solution. I just think it should be made more visible that there is a potentially troublesome issue here. /Rasmus
*** Bug 76478 has been marked as a duplicate of this bug. ***
*** Bug 106298 has been marked as a duplicate of this bug. ***
*** Bug 8424 has been marked as a duplicate of this bug. ***
*** Bug 297887 has been marked as a duplicate of this bug. ***
*** Bug 311326 has been marked as a duplicate of this bug. ***
Created attachment 185772 [details] Binary patch for org.eclipse.core.win32 As a holiday gift, I have hacked together a modified version of starter.exe to solve the problem of buffered process output. Extract the zip in the installation under the "plugins" directory (make a backup of the starter.exe in org.eclipse.cdt.core.win32 first). It works for CDT 7.0 or later. This solution was inspired by an article at http://www.codeproject.com/KB/threads/RTconsole.aspx using a console screen buffer as stdout handle for the spawned process. Note that this is not a perfect solution. It is possible to loose output, esp. when the program prints a lot to the console. But for the average use case it should work OK. Happy holidays!
(In reply to comment #32) > Created attachment 185772 [details] > Binary patch for org.eclipse.core.win32 > > As a holiday gift, I have hacked together a modified version of starter.exe to > solve the problem of buffered process output. > Extract the zip in the installation under the "plugins" directory (make a > backup of the starter.exe in org.eclipse.cdt.core.win32 first). It works for > CDT 7.0 or later. > > This solution was inspired by an article at > http://www.codeproject.com/KB/threads/RTconsole.aspx using a console screen > buffer as stdout handle for the spawned process. > > Note that this is not a perfect solution. It is possible to loose output, esp. > when the program prints a lot to the console. But for the average use case it > should work OK. > > Happy holidays! Thank you for your solution, but it doesn't help on my pc with Eclipse IDE for C/C++ Developers 64bit, Windows 7. :-(
*** Bug 355472 has been marked as a duplicate of this bug. ***
*** Bug 353679 has been marked as a duplicate of this bug. ***
*** Bug 333214 has been marked as a duplicate of this bug. ***
This bug is sadly not fixed. With latest Juno + CDT, using setvbuf( stdout, NULL, _IONBF, 0 ); result in a crash if stepping over a printf with F6. And if you just run over with run, the next breakpoint triggers text output in the console instead of the gdb trace corrupting the console output. Here is the code to repro, make sure when you run gdb to break at main, then step over setvbuf (everything is fine), step over printf (bad things happen). #include <stdio.h> int main() { setvbuf( stdout, NULL, _IONBF, 0 ); printf( "rar"); return 0; }
(In reply to comment #37) > And if you just run over with run, the next breakpoint triggers text output > in the console instead of the gdb trace corrupting the console output. One way to work around this is to have gdb create a separate console (cmd). To do that, create a .gdbinit file (you can point at in in the Debug configuration > Debugger) containing this: set new-console on I think this should be the default on Windows (which could be turned off in the Debug configuration).
*** Bug 412635 has been marked as a duplicate of this bug. ***
Siete dei pellai
i facing the same issue with cdt, and setvbuf(stdout, NULL, _IONBF, 0); did worked but im not sure whether using this in all programs ... is there any fix for this in windows 8.1 64bit..??
Since 8.3 there is support for winpty (see bug 419391), but by default it is not enabled for running programs, because winpty expects a terminal emulator on the other end. Still, it is possible to enable this by setting the system property "-Dorg.eclipse.cdt.core.winpty_console_mode=true". Disclaimer: Note that this is considered experimental, so please don't file bugs. It does not work with the debugger (use set new-console on instead).
*** Bug 479895 has been marked as a duplicate of this bug. ***
Greetings from the future. It has been 4-5 years since this issue has been troubling the undergraduates in our university, who learn programming in C as non-computer-scientists. It is not an option for us to tell them to "flush their buffers" or "make their standard output unbuffered". They do not, at any point, learn about the buffers, nor are put responsible of knowing about them. Those solutions had also been my own personal ways of offering a workaround to the suffering students, but with extreme care: They are fresh, and without a proper explanation, they will think this is C being stupid, while it is Eclipse being obnoxious at being an IDE, and trying and failing hard to provide their own console. Why not just don't, if you can't? I never had used Eclipse out of personal choice, to be frank. I have to, though, since for some reason our professors love it, and have invested in it. As far as I remember, I never had encountered anything similar to this atrocious bug in any other development environment I have used. I have found this during my research on this: https://devblogs.microsoft.com/commandline/windows-command-line-introducing-the-windows-pseudo-console-conpty/ Not fresh news, and rather almost a year old. Still, could it perhaps be the solution? I have read the whole thread, and have seen Anton Leherbauer asking for exactly this things existence, so that Eclipse may get fixed.
*** Bug 575323 has been marked as a duplicate of this bug. ***
(In reply to Marc-André Laperle from comment #38) > (In reply to comment #37) > > And if you just run over with run, the next breakpoint triggers text output > > in the console instead of the gdb trace corrupting the console output. > > One way to work around this is to have gdb create a separate console (cmd). > To do that, create a .gdbinit file (you can point at in in the Debug > configuration > Debugger) containing this: > > set new-console on > > I think this should be the default on Windows (which could be turned off in > the Debug configuration). This is now a debug configuration option (has been since 9.4): https://wiki.eclipse.org/CDT/User/NewIn94#Debug
*** Bug 560951 has been marked as a duplicate of this bug. ***
*** Bug 577601 has been marked as a duplicate of this bug. ***
