printf waits until main returns to display

**MK27** · 01-28-2010

Whew!

**brightmatter** · 01-28-2010

Issue solved:

To avoid this thread going down a road that might be more practice than solution, I suppose I had better just post the working code and say we are good. Apparently Windows XP is not a "normal operating system" and requires the stdout to be flushed. MK27 is right that this has become more OS that C syntax though I feel it is very helpful to know little tricks like setvbuf(stdout,NULL,_IONBF,0)... Just in case.

Code:

#include <stdio.h>

int main(void) {
	setvbuf(stdout,NULL,_IONBF,0);
	int n = 0;
	int i = 0;
	int left = 1;
	int right = 1;
	int temp = 1;

	printf("Enter an index: ");
	scanf("%d", &n);
	printf("Index: %d", n);
	if (n < 0 || n == 0) {
		printf("\nFibonacci index: %d\n", -1);
	}
	if (n == 1) {
		printf("\nFibonacci index: %d\n", 1);
	}
	for (i = 0; i < (n - 1); i++) {
		temp = right;
		right = left + temp;
		left = temp;
	}
	printf("\nFibonacci index: %d\n", left);

	return 0;
}

**MK27** · 01-28-2010

Well, that's why I said it sounds strange to me. I mean, it would suck to be starting out and get derailed by some weird problem that isn't your fault.

So, just to get this straight, you are saying you get a blinking cursor waiting for the scanf input before "Enter an index:" appears?

**brightmatter** · 01-28-2010

yep.

Well, not anymore because I am using the command you gave me.

**MK27** · 01-28-2010

Wow. What if you put a newline in there:

Code:

printf("Enter an index: \n");

Which I know you don't want to do that in this case, but it could be your buffer isn't flushed until a newline (or the buffer is full) which wouldn't be unusual.

It really is about the OS, by the way. But if you are used to Java, the Java VM/interpreter probably includes a mechanism to make it's own behavior uniform, taking the OS's behaviour into account. As you point out, C is not so fancy.

**_Mike** · 01-28-2010

Originally Posted by MK27

Just to remind you again: You are on the wrong path. There can be absolutely NO REASON to write your own print_string function (other than boredom, or as an exercise).

That (the underlined part) is an excellent reason to do it.

And what about OS abstraction? Or debug output?

Go look at some C source. NOBODY does this. NOBODY. You can be the first exception, but that should give you reason to stop and pause. You are confused about something, or something else is very wrong.

I've seen plenty of projects doing it. Can't remember any specific ones though.

**MK27** · 01-28-2010

Originally Posted by _Mike

I've seen plenty of projects doing it. Can't remember any specific ones though.

Well, fair enough, I just wanted to make a strong point here, vis, it would considered extremely strange for a beginner to have a need to do that. Like, if you read a C textbook, they are going to use printf() start to finish. If you can find even one book where in chapter 2, "input/output" they say:

First, C does not provide any standard, portable functions for console output. In this chapter, we'll learn how to write one.

...I'll eat my hat. That is more of an assembly language type project. We're not that low level.

It's not a bad exercise I guess, but probably brightmatter already understands stuff like datatypes, strings, bytes, how characters are represented, etc.

**brightmatter** · 01-28-2010

Well, I had tried this...

Code:

char ca[] = {'E', 'n', 't', 'e', 'r', ' ', 'a', 'n', ' ', 'i', 'n', 'd', 'e', 'x', ':', ' ', '\n'};
for(i = 0; i < sizeof(ca); i++) {
	putchar(ca[i]);
}

...and as you can see there is a "\n" on the end. It still would not print until it was at the return for main.
...I tried this with a string "dhfdxg\n" and it does the same thing. If it does not fflush or setvbuf(stdout,NULL,_IONBF,0) then it not only doesn't print but it corrupts my variable 'n' during the scanf.

**MK27** · 01-28-2010

Nb,

Code:

char ca[] = {'E', 'n', 't', 'e', 'r', ' ', 'a', 'n', ' ', 'i', 'n', 'd', 'e', 'x', ':', ' ', '\n'};

is exactly the same as:

Code:

char ca[] = "Enter an index: \n";

You may want to get into the habit of using "strlen()" with strings instead of "sizeof", because if you apply sizeof() to a char pointer, you'll get sizeof(char*) and not the length of the string pointed to.

Stuff like:

Code:

char *literal="hello world";

confuses this slightly, since literal is considered an immutable string literal, so sizeof will work there.

But strlen() works with all of them, presuming there is a valid string involved.

**brightmatter** · 01-28-2010

duly noted about card arrays.

Are you sure that strlen() does not require any non-standard libraries?

**anon** · 01-28-2010

No, <string.h> is a standard library.

Also, sizeof will lie about the length of strings like

Code:

char s[100] = "Hello";

**MK27** · 01-28-2010

Originally Posted by anon

Also, sizeof will lie about the length of strings like

Code:

char s[100] = "Hello";

Incorrect! The string is 5 characters long, which is what strlen() will report.

**_Mike** · 01-28-2010

strlen should be in string.h

Edit:
what the hell? Before I posted this then bright's question about strlen() was the last reply and now when I click submit 2 more replies pop up.. forum bug?

**brightmatter** · 01-28-2010

It was my impression that sizeof didn't lie so much as it just includes the null terminator at the end of a C-style char array

**_Mike** · 01-28-2010

char s[100] = "Hello";
sizeof(s) == 100
strlen(s) == 5

char* s = "This is a long string!";
sizeof(s) == 4
strlen(s) == 22

Using sizeof for string length is not reliable..