By what i have read, fgets is the best and safest way to read a string from the user.
The problem is that my program has a thread where a printf is executed. Is seems the \n at the end of the printf is triggering the fgets.
Any way to get around this, or do i have to use another function to read the string?
fgets() will add a \n to the buffer you get back if there is room.
Ways of removing the \n if there is a problem with it being there are in the FAQ.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
That is not the problem. What i think is that when the printf is executed, the \n at the end of it, simulates the uses pressing enter, so it reads without anything been typed...
So, you have a multi-threaded application?
Mainframe assembler programmer by trade. C coder when I can.
yes.
Wow.
(that's about all I can say with the information you have provided)
Mainframe assembler programmer by trade. C coder when I can.
Why not use fprintf and stderr then? Presuming it's okay.
But it sounds to me like you would be much better off finding out how to wait to use the terminal in situation like this, which must be common.
C programming resources:
GNU C Function and Macro Index -- glibc reference manual
The C Book -- nice online learner guide
Current ISO draft standard
CCAN -- new CPAN like open source library repository
3 (different) GNU debugger tutorials: #1 -- #2 -- #3
cpwiki -- our wiki on sourceforge
Is that possible? printf writes at the stout and fgets reads from the stdin.Originally Posted by Ironic
So when you type something it will be at the stdin and echoed at the stdout.
fgets will check a pointer end if it is at the end of the stdin it will freeze and wait for input to read. printf will just write at the stdout.
Well, that is generally what I understand without a lot of details. Even if it is multithreaded I don't see how they would interfere
I agree with c_ntua: It seems unlikely that fgets() directly interferes with printf(). It may cause locks of the stdin/stdout to be locked so that your printf() is blocked until the fgets() is finished, perhaps. I'm not sure whether that is the case. But for sure, printf() operates on stdout, fgets() operates on the file you give it, and if you give it stdin, then that's a different file altogether.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
tks, maybe the problem is that data is still in stdin.
How can i delete remaining data in stdin, if fgets doesn read all the bytes itś supposed to?
usual fflush(stdin) doesn't work...
So what input data do you have, and what does your code look like? And what do you get?
fflush(stdin) is not reliable, portable and undefined according to the C standard - so best not to use that. There are other ways to read clear the data from the input. See the FAQ on the subject of "How do I clear the input buffer" or some such.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
Post the functions that your threads use. Maybe you are calling two fgets(), one for each thread? Maybe then one reads everything, blocking the other, and when there are data again the other reads? Using I/O is simple when there is one thread. It just blocks and waits. When you have more threads though things are not that simple.
We can just guess with the information we have.
Whatever way you have to flush stdin, to be more sure of what you are doing, do it only at one thread. Synchronize everything at one point, one thread fflushes and then everything starts again. So you are sure of what you are doing.
If one thread reads and the other writes I don't think you will have a problem in the logic of the program. But the prints and the echoes might get mixed up.
In a few words give us info!
If fgets() leaves something in the input stream, it's probably because you either pressed enter twice, or because too much data was typed to fit into fgets()'s buffer. In case of the latter, you can always just call fgets() again.
No, that's not really the same as flushing the input, but it lets you process that extra data. If you really want to flush the remaining data in a portable manner, you could try something like this:
That will skip all of the remaining data on a line.Code:int c; do { c = getchar(); } while(c != '\n' && c != EOF);
dwk
Seek and ye shall find. quaere et invenies.
"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell
Other boards: DaniWeb, TPS
Unofficial Wiki FAQ: cpwiki.sf.net
My website: http://dwks.theprogrammingsite.com/
Projects: codeform, xuni, atlantis, nort, etc.
> How can i delete remaining data in stdin, if fgets doesn read all the bytes itś supposed to?
What do you mean "supposed to"?
fgets() is only supposed to
- return at EOF
- return when the buffer is full
- return when it finds a \n
If you're returning a buffer without a \n, then use a bigger buffer, or call fgets() again.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
