«

Ron Ford wrote:

> On Thu, 03 Jul 2008 12:02:58 GMT, Richard Bos posted:
>
>> Ron Ford <> wrote:
>>
>>> I see. What I was getting at was more like:
>>> putchar(anything)!=EOF ....
>>
>> You may have tried to get at that, but since it wasn't in the OP's
>> posted code, it would be hard to reach it.
>>
>>> The test against anything for a putchar call seems prudent but ends
>>> up being a lot of extra keystrokes and code.
>>
>> A lot? Rather an exaggeration, isn't it? If you do it right, that
>> check for EOF will double as your loop termination condition, which
>> you would have needed anyway.
>
> Out of n tests against EOF, how many do you think were unnecessary?

None. In a typical read loop each return of getc must be tested for EOF.
If feof and ferror are called for each character for ensuring against
unlikely situations then the number of tests are doubled.

In article <g4q0v5$utf$>,
santosh <> wrote:

>>>> I see. What I was getting at was more like:
>>>> putchar(anything)!=EOF ....

[...]

>None. In a typical read loop each return of getc must be tested for EOF.

Somewhere along the line the question seems to have changed from
putchar() to getc(). It's certainly not always necessary to test
every return value while writing.

-- Richard

--
Please remember to mention me / in tapes you leave behind.

Richard Tobin wrote:
> santosh <> wrote:
>
.... snip ...
>
>> None. In a typical read loop each return of getc must be tested
>> for EOF.
>
> Somewhere along the line the question seems to have changed from
> putchar() to getc(). It's certainly not always necessary to test
> every return value while writing.

If you can affort to ignore write errors. Which is usually so, or
they are extremely rare.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

Richard Tobin wrote:

> In article <g4q0v5$utf$>,
> santosh <> wrote:
>
>>>>> I see. What I was getting at was more like:
>>>>> putchar(anything)!=EOF ....
>
> [...]
>
>>None. In a typical read loop each return of getc must be tested for
>>EOF.
>
> Somewhere along the line the question seems to have changed from
> putchar() to getc(). It's certainly not always necessary to test
> every return value while writing.

Oops missed that. For putchar, testing for EOF may be over-engineering,
at least for stdout and stderr.

santosh wrote:

> Richard Tobin wrote:
>
>> In article <g4q0v5$utf$>,
>> santosh <> wrote:
>>
>>>>>> I see. What I was getting at was more like:
>>>>>> putchar(anything)!=EOF ....
>>
>> [...]
>>
>>>None. In a typical read loop each return of getc must be tested for
>>>EOF.
>>
>> Somewhere along the line the question seems to have changed from
>> putchar() to getc(). It's certainly not always necessary to test
>> every return value while writing.
>
> Oops missed that. For putchar, testing for EOF may be
> over-engineering, at least for stdout and stderr.

No correct that. Any write to stdout must certainly be verified and any
failure reported on stderr. But there is no point in verifying writes
to stderr, since there is usually nothing that can be done on failure.

But I wonder how much C code meticulously tests putchar/printf etc. In
much code that I have encountered even writes to named files were
unverified.

If there is one thing that I find somewhat frustrating in C, it is the
necessity to constantly test the execution of almost every standard
library and user-defined function at each call, if you want robust
code.

In article <g4q8vd$m82$>,
santosh <> wrote:

>>> Somewhere along the line the question seems to have changed from
>>> putchar() to getc(). It's certainly not always necessary to test
>>> every return value while writing.

>> Oops missed that. For putchar, testing for EOF may be
>> over-engineering, at least for stdout and stderr.

>No correct that. Any write to stdout must certainly be verified and any
>failure reported on stderr.

I said you don't have to test every return value, not that you don't
have to test for errors. For output it's often adequate to test
for errors at the end of the output instead of after every call:
extra failing writes are usually unimportant.

Obviously this doesn't apply to input, where the values read usually
determine when you stop reading.

-- Richard
--
Please remember to mention me / in tapes you leave behind.

In article <>,
CBFalconer <> wrote:

>> Somewhere along the line the question seems to have changed from
>> putchar() to getc(). It's certainly not always necessary to test
>> every return value while writing.

>If you can affort to ignore write errors. Which is usually so, or
>they are extremely rare.

I don't suggest ignoring them in general, just not checking after every
character. Real i/o errors are rare on general-purpose computers, but
write errors caused by full disks, unplugged memory sticks, and closed
terminal sessions are quite common.

-- Richard
--
Please remember to mention me / in tapes you leave behind.

pete wrote:

> pete wrote:
>> santosh wrote:
>>
>>> No correct that. Any write to stdout must certainly be verified and
>>> any failure reported on stderr. But there is no point in verifying
>>> writes to stderr, since there is usually nothing that can be done on
>>> failure.
>>
>> Would you expect greater success with the standard error stream
>> if it were associated with the same file as the standard input
>> stream?
>
> That should be "as the standard output stream?"

No. However, in many cases stdout happens to be redirected to a disk
file while stderr is still linked to the terminal. In such cases it
might be worthwhile to log failure on stdout to stderr.

<snip>

CBFalconer <> wrote:
> Richard Tobin wrote:
> >
> > Somewhere along the line the question seems to have changed from
> > putchar() to getc(). It's certainly not always necessary to test
> > every return value while writing.
>
> If you can affort to ignore write errors.

Or you check for them (via ferror) at the end, like most people do.

-- Larry Jones

These child psychology books we bought were such a waste of money.
-- Calvin's Mom

Ron Ford <> wrote:

> On Thu, 03 Jul 2008 12:02:58 GMT, Richard Bos posted:
>
> > Ron Ford <> wrote:
> >
> >> EOF has alwyas been negative one on my impkementation.
> >
> > That's as may be, and it is indeed by far the most common value, but all
> > the Standard demands is that EOF is negative. Besides, EOF is both
> > clearer, and only a single character longer, than -1.
>
> My impkemenation is sometimes more clever than the monkey on the keyboard.

Exactly. So use EOF, which is guaranteed by the Standard to be valid for
all implementations, not -1, which your monkey believes to be valid
right here, right now.

Richard