Increasing the stack size of a Thread...very Urgent

Quote:

---

Originally Posted by ScorpionChief

That's the reason why it's not required in "C". Implicit pointer conversions from void* is allowed in ANSI C.

---

You are right. But still I feel it is better to be explicit about such implicit conversions.

Quote:

---

Originally Posted by Paul McKenzie

OK, so how does this resolve the OP's problem?

---

I guess pointing such things are very common in forums. There are lot of things which OP's don't ask but people in forum do tell about them. Do this and don't do that...

Quote:

---

Originally Posted by Paul McKenzie

The original code from the OP did have a cast, so you should direct your comment to him/her.

---

I should have pointed to both.

Quote:

---

Originally Posted by Paul McKenzie

Maybe the OP is using this code in a C and C++ module and is experimenting with it. The lowest common denominator that works for both C and C++ is to cast.

---

Sir, OP talked about using "C" on Unix Solaris.

Quote:

---

Originally Posted by exterminator

Johny - the standard IO is unbuffered by default.

---

Nope.
C streams are buffered (except stderr, usually).

Quote:

---

Originally Posted by SuperKoko

Nope.
C streams are buffered (except stderr, usually).

---

Quote:

---

Originally Posted by C working paper

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.

---

That implies that console output via stdout is line buffered at most (e.g. it autoflushes when a '\n' is output). I don't have the C89 standard to check against.

Quote:

---

Originally Posted by TomWidmer

That implies that console output via stdout is line buffered at most (e.g. it autoflushes when a '\n' is output). I don't have the C89 standard to check against.

---

In practice, because of the as-is rule, implementations tend to have a fully buffered stdout flushed when input is requested from the user (or perhaps after a delay, such as the v-sync).
Whether the as-is is respected by these implementations, or not, doesn't even matter since I have the experience that printf is unreliable for outputing debug info in a program that crashes.

And C streams are usually buffered for file I/O (even when these files are accessed through stdin/stdout).

Quote:

---

Originally Posted by ScorpionChief

I guess pointing such things are very common in forums. There are lot of things which OP's don't ask but people in forum do tell about them. Do this and don't do that...

---

I copied what the OP tried, and wrote a small program given what he gave us. Casting or not casting makes absolutely no difference in the program's behavior.

Besides, as exterminator pointed out, I also feel it is better to be explicit about the conversion, since this is a source of many bugs in 'C' which can be prevented with explicit casting.

Regards,

Paul McKenzie

Quote:

---

Originally Posted by Paul McKenzie

I copied what the OP tried, and wrote a small program given what he gave us. Casting or not casting makes absolutely no difference in the program's behavior.

---

Ok, fine. It might not be a problem in your code but there can be a problem in case stdlib.h, the header which declares malloc, is not included. If the return of malloc is cast then the error which would be flagged is hidden, resulting in a difficult to find bug.
Also, during maintenance, if the type of the pointer changes but the cast is not changed, once again there is a difficult to find bug.
So, I prefer not to cast.

I guess we both know what's right here and we can stop this discussion here.

Quote:

---

Originally Posted by SuperKoko

In practice, because of the as-is rule, implementations tend to have a fully buffered stdout flushed when input is requested from the user (or perhaps after a delay, such as the v-sync).
Whether the as-is is respected by these implementations, or not, doesn't even matter since I have the experience that printf is unreliable for outputing debug info in a program that crashes.

And C streams are usually buffered for file I/O (even when these files are accessed through stdin/stdout).

---

That's presumably a violation of the as-if rule, since I imagine that they don't flush complete stdout lines when a volatile variable is read or written. Looking at GNU libc, I think it correctly implements line buffering, which Microsoft's CRT seems to leave stdout completely unbuffered when it is attached to a terminal (in both cases, when stdout is redirected to a file, it is buffered, as allowed by the standard).

Quote:

---

Originally Posted by TomWidmer

That's presumably a violation of the as-if rule, since I imagine that they don't flush complete stdout lines when a volatile variable is read or written. Looking at GNU libc, I think it correctly implements line buffering, which Microsoft's CRT seems to leave stdout completely unbuffered when it is attached to a terminal (in both cases, when stdout is redirected to a file, it is buffered, as allowed by the standard).

---

No, that's not a violation of the rule. What's the standard output is implementation-defined.
If the implementation says that data is only visible after the v-sync or every two seconds, it's legal.
Moreover line buffering still is buffering.

Quote:

---

Originally Posted by SuperKoko

No, that's not a violation of the rule. What's the standard output is implementation-defined.
If the implementation says that data is only visible after the v-sync or every two seconds, it's legal.
Moreover line buffering still is buffering.

---

I would take an unqualified "buffered" to mean "fully buffered" in the C standard's parlance (particularly when the conversation relates to logging, which is usually line based). YMMV.