getc() != fgetc() ??

[arun]

Hello,

I use a Borland C++ 3.1 for Dos compiler, in Ansi C source mode.

The result of compiling the following simple program depends from the way
it was saved.

If it was saved with .cpp extension (default) no matter.

If it was saved with .c extension, I get a warning "code has no effect",
at the getc(stdin) line.

Changing getc with fgetc no warning appears.

#include "stdio.h"
main() {
printf("press Enter...");
getc(stdin);
return 0;
}

I thought getc and fgetc were the same thing. Isn't it true?
Or the problem comes from the compiler?

Thank you.

 

[Shao Miller]

Hello,

I use a Borland C++ 3.1 for Dos compiler, in Ansi C source mode.

The result of compiling the following simple program depends from the way
it was saved.

If it was saved with .cpp extension (default) no matter.

If it was saved with .c extension, I get a warning "code has no effect",
at the getc(stdin) line.

Changing getc with fgetc no warning appears.

Do you mean using 'fgetc' and with a ".c" extension, still?

#include "stdio.h"

I tend to use:

main() {

Please use:

int main(void) {

if you do not care about having parameters in the 'main' function.

printf("press Enter...");
getc(stdin);
return 0;
}

I thought getc and fgetc were the same thing. Isn't it true?
Or the problem comes from the compiler?

In N1256.PDF, we have 7.19.7.5p2, which states:

"The getc function is equivalent to fgetc, except that if it is
implemented as a macro, it may evaluate stream more than once, so the
argument should never be an expression with side effects."

 

[Eric Sosman]

Hello,

I use a Borland C++ 3.1 for Dos compiler, in Ansi C source mode.

The result of compiling the following simple program depends from the way
it was saved.

If it was saved with .cpp extension (default) no matter.

The .cpp extension probably means it was compiled as C++ source
rather than as C source. C and C++ have much in common, but they are
as different as Latin and Italian, and have different rules. If you
wish to pursue the C++ aspects, comp.lang.c++ is the forum to frequent.

If it was saved with .c extension, I get a warning "code has no effect",
at the getc(stdin) line.

The warning is misleading at best, because the statement does
in fact have an effect: It consumes and discards one character from
the standard input, or sets the appropriate exception flags if
standard input reports error or end-of-stream. Either way, the
statement does in fact have an effect.

However, compilers are allowed to emit as many warnings as they
like, about whatever topic. They might warn that getc(stdin) is
equivalent to getchar(), or that the printf() produces no '\n' to
end the line, or that the code was last edited on a Tuesday and
statistical analysis of previous edits indicates you make more
mistakes on Tuesdays than on any other day. As long as the compiler
accepts the code (if it's valid), it can emit the entire Magna Carta
as a diagnostic if it's so moved.

Changing getc with fgetc no warning appears.

Okay. (Shrug.)

#include "stdio.h"

Here's something a compiler might warn about and have reason

main() {

Some compilers might warn that `int main()' or `int main(void)'
would be better. Some compilers (those that follow the latest "C99"
language definition) *will* warn about this (that is, they will "emit
a diagnostic message;" the Standard does not distinguish between
different severities of diagnostics).

printf("press Enter...");
getc(stdin);
return 0;
}

I thought getc and fgetc were the same thing. Isn't it true?
Or the problem comes from the compiler?

getc(x) and fgetc(x) have the same effect as long as `x' has
no side-effects of its own. "Have the same effect" is not the
same as "are the same thing." If `x' is an int between 1 and 10,
`x >>= 4' and `x = 0' "have the same effect" but are not (in any
reasonable sense) "the same thing."

In short, I take issue with your characterization of this as
a "problem." Sometimes you get a warning, sometimes you don't.
Sometimes the warnings are helpful, sometimes they're misleading.
Hey, that's life.

 

[Angel]

I thought getc and fgetc were the same thing. Isn't it true?
Or the problem comes from the compiler?

getc() may be implemented as a macro and may evaluate its arguments more
than once. fgetc() is a true function and will not do that, but it may be
a bit slower.

It's possible that the macro expansion leads to code that ultimately
does nothing because the compiler optimized some stuff away. The "wait
for enter" effect is done by the environment, not by getc().

You could try running the code through cpp only to see what it looks
like after macro expansion.