[CLOSED] Odd behaviour of C code running on local compiler (C4Droid 7.00)

Question

Problem details:

I'm noticing a change in behaviour of my local C compiler (C4Droid). The change is noticeable when reading input in a loop.

In the old days (previous version) I can use printf() to show an input message, followed immediately by a scanf() prompt (in a loop), and the code runs in correct sequence (show the message first and input prompt afterwards).

But recently I noticed that I have to flush the output stream to achieve the same result. Without flushing the output stream the scanf() input prompt appears before the message printed by printf().

NOTICES:
* This behaviour is noticed on C4Droid v7.00.
* I'm not aware how it is like with any other C compiler/IDE.
* It doesn't appear to happen when reading input normally (without a loop).
* I don't suppose this behaviour is obviously noticeable in SoloLearn Code Playground
* I'm not sure what am I doing wrong in the old days, but it used to work fine.

https://code.sololearn.com/cyJPLZFsrOr3/?ref=app

Any explanation would be appreciated .

TIA,

Answer 1

Ipang I was not reluctant, sorry if I made you feel so ^^ I think in your case, fflush is the best way to do but I do not know much on this topic ^^

Answer 2

Ipang well, the first answer of your link should be the right one. I think the old behavior was C4Droid specific. Maybe because they use an intermediary file and didn't configure it properly or because they used an interpreter instead of a compiler, but I guess this is an information that they may never disclose !

Answer 3

When you do not put an end line, what you want to display might stay in cache because of some optimizations. It might simply be that C4Droid updated its compiler or the way it is called and that added this optimization

Answer 4

Indeed it is possible Baptiste E. Prunier

I just feel a little awkward in case this is C4Droid specific implementation, because following their scheme (immediate flush) would probably mean different code behaviour on other compilers.

I only found this one old SO discussion that seems to be relevant, but still unable to draw a conclusion from it, considering the date, controversial comments, and that OP in that discussion did not specifically state the use of C4Droid (I'm guessing he is not).

https://stackoverflow.com/questions/1716296/why-does-printf-not-flush-after-the-call-unless-a-newline-is-in-the-format-strin

Thank you very much for your time and answer 🤗

Answer 5

As an illustration, I meant to display an input prompt and get the input on the same line, as follows (assume 5 as user given input):

Enter a number to square: 5

And give output on the next line:
5 * 5 = 25

Use of \n helps with flushing output, but that would mean the user input value will be read on a different line to that of the input prompt. And as I understand it, some people suggests that flushing is "expensive". So if at all possible I would avoid it since I want to make the code to prompt for, and read user input in a loop.

Answer 6

Baptiste E. Prunier
Thank you once again,

Then I can conclude that manual output buffer flush is the standard way for most C compilers? and that only (old version of) C4Droid implemented a different way?

Also, if you don't mind, I need help understanding what these people say in the SO discussion, which seems contradictory/confusing to me (maybe it's my English Idk)

* Comment by Seppo Enarvi
"the standard input and standard output streams are fully buffered if and only if the stream can be determined not to refer to an interactive device."

* Answer by paxdiablo
"Standard output is line buffered if it can be detected to refer to an interactive device, otherwise it's fully buffered."

So I can't conclude when I/O stream is fully buffered, or line buffered. How do I know whether it refers to an interactive device or not, so confusing 😂

Answer 7

Thinking about it, I think it is stream dependant and not compiler / os dependant.
Line buffered means it writes to the stream when the line is full
Fully buffered means it writes directly when you enter something
Interactive stream takes inputs interactively (like the terminal, unlike a file)
It might be possible. First you can know if the stream is a terminal thanks to the isatty function
There might be a getstreambuff function or something like that to get the buffer of the stream. If it is NULL, it is fully buffered

Answer 8

I guess I have misunderstood something, this far here's how I understand it,

Line buffered waits for a \n in the stream buffer before the buffer is sent to destination, unless specifically flushed, like this behaviour with C4Droid.

Fully buffered waits for the buffer to get filled up before buffer is sent to destination, unless specifically flushed, like how C++ std::cout behaves.

Unbuffered means buffer will be sent directly to destination without any caching mechanism, like stderr or std::cerr.

A phone supports interactive stream right? so the fact that a phone is interactive is the reason why C4Droid implements line buffered strategy?

Can we take a conclusion that (in most common C compilers) a manual output stream flush will be necessary for the said purpose (to get input at the same line with input prompt) Baptiste E. Prunier ?

I really need a firm ground about this so I can feel safer writing such code (with manual stream flush), portability speaking 😁

Answer 9

For the three buffer things I guess yes

It is not because it is supported on the device, it depends on the output stream which can vary on the same device

Well, I would say yes just because you are not sure of which stream is used or how it is configured and you want it to be flushed at a precise point

Answer 10

Baptiste E. Prunier
Thank you again for being patient with my question 👍

I'm sensing reluctance in your most recent reply. Is there possibly another way to do what I ask for maybe? to get input value on the same line with the prompt? some other way which can work safely amongst the common C compilers or IDE?

Answer 11

Baptiste E. Prunier
Thank you so very much.
And I know even less about this, that is why I asked.
Really appreciate all your time and patience.
I'm marking this case closed
Big Thanks 🤗

Answer 12

Ipang glad I was of any help then ! 😁