Keith Thompson wrote, On 19/10/07 07:29:
> Ben Pfaff <blp@cs.stanford.edu> writes:
>> CBFalconer <cbfalconer@yahoo.com> writes:
>>> int fcopy(char const *dst, char const *src) {
>>> FILE *sf, *df;
>>> int ch
>>>
>>> if (sf = fopen(src, "r") { /* text files */
>>> if (df = fopen(dst, "w") {
>>> while (EOF != (ch = getc(sf))) putc(ch, df);
>>> fclose(df);
>>> }
>>> fclose(sf);
>>> }
>>> return sf && df; /* non-zero for success */
>> I think that this is a bad idea: it is a lot like checking the
>> value of a pointer after it has been freed (often fclose will
>> actually call free on the stream, in fact). I'm sure it works in
>> practice on almost every implementation though.
>>
>>> }
>
> If the first fopen() fails, no value is assigned to df, and accessing
> it invokes undefined behavior.

If the first fopen fails sf will be a null pointer and short circuit
evaluation ensures that df is not accessed, so it is OK.

> In addition, I think you're write; though fclose() cannot change the
> value of of its argument, it can cause it to become indeterminate.
> (In practice, it will probably appear to be be null or non-null after
> fclose() if it was, respectively, null or non-null before fclose().)

Agreed.
--
Flash Gordon