Keith Thompson" ha scritto nel messaggio > "io_x said:
"Nick Keighley" ha scritto nel messaggio
there are some subjects where being pedantically right is over kill.
You can be about right or good enough. Unfortunately computer
programming isn't one of those subjects. The computer does exactly
what you tell it. Absolute corretness is important.
instead of "Absolute correctness", what about one
"relative correcteness" at last until when some error goes
out from some test, or from the use?
[and that error is so importat to be correct]
There are some things that are really easy to get right, including
getting the return type of getc right. Absolute correctness isn't
always possible, but getting the little things right is.
if you mean how getc is written: i see now in K&R2 getc() is a macro
in which there is the function _fillbuf(),
there could be errors, who know it?
In K&R2 there is an example of an implementation of fopen() and getc()
in section 8.5.
This has nothing to do with how any actual library implementor performs
the task. If the actual library implementor should create a function
called _fillbuf(), which resides in the implementation's namespace, and
if _fillbuf() was indeed used as shown in the sample implementation in
the book, then the library implementor is responsible for the
correctness of _fillbuf(). If getc() does not work as defined in the
standard and the reason is that they have done something wrong with
_fillbuf() then you should report the error to your library vendor. I
guess that such an errant version of a C library does not exist.
if gets "little things" right is possible, than it is possible not
doing error in assembly: what is more small than these instructions?
Colorless green ideas sleep furiously.