Richard Bos said:
Don't use gets(). Ever. It is an irrepairable security hole, because
there is no way to tell it where its buffer stops and it will start to
munge other variable or worse..
I understand that. That wasn't the question. I also understand that they
handle the newline character differently and that when you use fgets() to
bring a string you need to also check whether the newline character is at
the end of the string in order to determine if the entire string was read in
versus hitting the count limit. My question wasn't about any of that. All of
those are answered in the FAQ quite extensively. None of this would be any
different if the functions where named Bob and Sue. My question was limited
to a querry about the nameing convention.
That's deceptive, though. It's true in the case of (f)printf() and
(f)scanf(), but puts(s) actually does something subtly different from
fputs(s, stdin);
I understand that. Again, that is addressed more than adequately by the FAQ.
That wasn't the question. The question only has to do with the naming
convention chosen.
No, we don't. There is no such thing as fgetchar() and fputchar() in C.
I'll take your word for that. They are in every stdio.h I have every worked
with, but that's not a very long list. In fact I just looked at the
portability list for those arguments and see that they are not listed as
being ANSI compliant. So thanks, even though it still doesn't answer the
question that was asked.
In each case the pairs of functions perform the same task.
No, they don't. fgetc(instream) gets a character from instream.
getc(instream) does the same thing superficially, but it is allowed to
evaluate its parameter more than once. This means that
fgetc(instream[i++]) is safe, but getc(instream[i++]) is not safe; it
might evaluate i++ more than once, even more than once between two
sequence points, and thus cause undefined behaviour. The other side of
the coin is that getc() could be slightly faster than fgetc().
getchar() is equivalent to getc(stdin). Since stdin does not contain
side effects, this is both safe and efficient.
The same thing is true for fputc()/putc()/putchar()/stdout, with the
proviso that putc() is only allowed to evaluate its second argument more
than once; putc(line[i++], outstream) is safe, but putc(i,
outstream[j++]) is not.
Although it still doesn't answer the question that was asked, this is
definitely completely new information to me and so I appreciate it. I'm
trying to picture the process flow that allows a function to evaluate its
parameters more than once and can't. While I know that this is
implementation specific, my mental picture of the process is that the
parameters are evaluated and the resulting values are placed on a stack.
Necessary context is then saved and program control is turned over to the
function's code that then accesses the evaluated values of the parameters
from the stack based on the value of the stack pointer. After doing whatever
it wants to with those values, at calculates a return value (if any), pops
all of the arguments off the stack, and places that value on the stack and
returns control to the calling function that then pops the return value from
the stack placing the stack back to its original condition prior to the
function call.
I would be greatful for an alternate picture that allows multiple
evaluations of a function's arguments for a single call to the function.
I presume it was for historical reasons; that is, because it was the way
pre-Standard C implementations usually did it, and changing it would
have broken too much existing code.
This is my general assumption, but I'm hoping that, like the implied type
casting of chars and shorts to ints with certain functions for compatibility
with legacy code, that I can get a more definite answer. In particular, if
there was a reason that 'f' was used to distinguish getc() from fgetc(). If
the performance you mentioned was the other way around I could almost see
the two being getc() and fast_gets(), but of course that would only be a
guess on my part and not what I am looking for.
Thanks.