0

Here, my code gives weird results in the online geeksforgeeks compiler.

#include <stdio.h> main() { printf("\nhai\bas\rha\n"); }

output: haiasha

but I think correct output is haas.

Online compiler ink : http://code.geeksforgeeks.org/paWwuv

Why compiler give wrong output? please help me.

Improve this question
2
  • 1
    It depends on how the standard output device responds to backspace and return characters, not the compiler. The output is actually a sequence of characters '\n', 'h', 'a', 'i', '\b'`, etc (i.e 11 characters), regardless of whether you see all of them on the particular output device. Commented Sep 13, 2016 at 10:45
  • int main(). Just main() is not valid C anymore. Commented Sep 13, 2016 at 14:13

4 Answers 4

Reset to default
2

The online compiler prints to an html page, not to a console. \b is displayed differently by a browser than by a terminal window.

If you run the code in the online compiler, then view the page source you can see that all characters you print are there.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

1

It is not a compiler error. I would blame your terminal. Here is my output on a debian machine:

$ make so cc so.c -o so $ ./so haas

To be sure the program actually emits the charcode you expect, you can pipe the output to xxd for instance.

Also, if you return nothing, your main function should be void. When no type qualifier is used (which I find ugly), int return type is assumed.

Improve this answer

5 Comments

"Also, if you return nothing, your main function should be void.". That's incorrect. Return type of main should be int, not void. And it should be explicitly declared as int, since there is no "implicit int" rule in C anymore. And you can safely "return nothing" from main, since the compiler will implicitly return 0 for you in such cases.
@AnT Right! I remember something related to main in the standard. But actually it was related to its arguments. Do you have a ref on not having an implicit int anymore?
Well, if you open a copy of C99, at the very beginning it contains a list of major changes from C89/90. One of the items in that list explicitly mentions the abolition of "implicit int" rule. The rest of the standard text is modified accordingly.
Thanks :) I was peeking inside open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf (quick google search, not the best obviously...) The rationale (open-std.org/jtc1/sc22/wg14/www/docs/C99RationaleV5.10.pdf) talks about that in 6.7.2 but for types. My point being: standard are (somehow) hard to get, and hard to read.
I was referring to the "Foreword" section of the document, which is present in n1256 as well.
1

The "correct" output in this case is \nhai\bas\rha\n, exactly as you supplied it to printf, with \n, \b and \r standing for the corresponding special characters (or character combinations).

But how this output will look on a specific output device depends on the properties and capabilities of that device. It just so happens that the output device used (simulated) by your online compiler displays that sequence as haiasha.

It appears that your expectations are based on the behavior of a "typical" display terminal. Meanwhile, online compilers don't output anything directly to any "display". They intercept the standard output and then postprocess it for representation on a Web page. What you see is the result of that postprocessing.

Improve this answer

Comments

0

\b is a special character. The terminals usually interpret it as "move the caret one character to the left". As a consequence the next printed character overwrites the last character printed before \b.

However, in other contexts the \b character may be interpreted in a different way. For example, in a file it is nothing but a regular byte (with value 8).

Improve this answer

Comments