Extent of the "as-if" rule

[Sidney Cadot]

Hi all,
In a discussion with Tak-Shing Chan the question came up whether the
as-if rule can cover I/O functions. Basically, he maintains it can, and
I think it doesn't.

Consider two programs:

/*** a.c ***/
#include <stdio.h>
int main(void)
{
fopen("somefile ","rb");
return 0;
}

/*** b.c ***/
in main(void)
{
return 0;
}

Would it be legal for a compiler (through optimization), to emit the
same code for program a.c and b.c ?

I'd welcome a reference from the standard.

Best regards,

Sidney

[glen herrmannsfeldt]

Barry Margolin wrote:

(snip regarding side effects of fopen())

But it may only be updated if you actually read something from the file;
the act of opening the file in read mode might not update it (consider a
file on an NFS server -- there's nothing in NFS that corresponds to
open() or close(), the server only sees the directory lookup and the
read/write operations).

There is an additional effect with NFS that I believe is system
dependent, and that is whether the last access time is updated
from the client clock or the server clock.

Of course, the C standard doesn't say anything about that, either.

-- glen

[Douglas A. Gwyn]

pete wrote:

A conforming implementation need not produce any output
nor accept any input during the execution of a program.

Strictly speaking, it needs to make the attempt or else
it hasn't implemented the semantics as specified. But
so much of file behavior is environment-dependent that
sanity in that department becomes more a "quality of
implementation" issue; i.e., the marketplace decides
whether an implementation can get away with constant
I/O failure. Odds are that no hosted implementation
would succeed without being able to perform I/O using
the most common kinds of file on a platform. There are
even implementations of C for embedded system that
manage to support file I/O one way or another (e.g.,
over the debugger console port).

[pete]

CBFalconer wrote:

pete wrote:

Is it legitimate for a function like puts,
to return at the first sign of EOF or must it keep hammering away, regardless of EOF

I would recommend the immediate return. Once the EOF has been
received something has gone wrong, and the string will not be
properly output. Any further 'hammering' may disturb the error
status, which in turn will prevent proper diagnostics.

Thank you.

--
pete

[Peter Nilsson]

"CBFalconer " <cb********@yah oo.com> wrote in message
news:40******** *******@yahoo.c om...

pete wrote:

... snip ...

And now if I may change change the topic to some old business:

Is it legitimate for a function like puts,
to return at the first sign of EOF, like this:

int puts(const char *s)
{
while (*s != '\0') {
if (putchar(*s) == EOF) {
return EOF;
}
++s;
}
return putchar('\n');
}

or must it keep hammering away, regardless of EOF, like this:

int puts(const char *s)
{
int eof = 0;

while (*s != '\0') {
if (putchar(*s) == EOF) {
eof = 1;
}
++s;
}
return putchar('\n') == EOF || eof != 0 ? EOF : 1;
}

I would recommend the immediate return.

So would I.
Once the EOF has been
received something has gone wrong,
[Assuming UCHAR_MAX <= INT_MAX.]
and the string will not be
properly output. Any further 'hammering' may disturb the error
status, which in turn will prevent proper diagnostics.

What 'error status' will be disturbed? Neither puts nor putchar can reset
the end-of-file or error indicator.

I'd argue the early return purely on the basis that that puts should
(IMHO)return EOF immediately an error is reported by fputc.

--
Peter

[CBFalconer]

Peter Nilsson wrote:

"CBFalconer " <cb********@yah oo.com> wrote in message

... snip ...

Once the EOF has been
received something has gone wrong, and the string will not be
properly output. Any further 'hammering' may disturb the error
status, which in turn will prevent proper diagnostics.

What 'error status' will be disturbed? Neither puts nor putchar
can reset the end-of-file or error indicator.

But a subsequent error may be the result of the initial error.
There are no specifications about this AFAIK, and it is up to the
i/o system designer.

--
Chuck F (cb********@yah oo.com) (cb********@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!

[pete]

CBFalconer wrote:

Peter Nilsson wrote:

"CBFalconer " <cb********@yah oo.com> wrote in message

... snip ...

Once the EOF has been
received something has gone wrong, and the string will not be
properly output. Any further 'hammering' may disturb the error
status, which in turn will prevent proper diagnostics.

What 'error status' will be disturbed? Neither puts nor putchar
can reset the end-of-file or error indicator.

But a subsequent error may be the result of the initial error.
There are no specifications about this AFAIK, and it is up to the
i/o system designer.

There's a scene on The Simpsons where Bart joins the
Junior Campers and faints. Ned tells one of the kids to give
Bart mouth to mouth. At first contact, Bart wakes up screaming
and the kid says "Should I keep doing it?"
Stopping makes sense to me, but I don't see in the standard
what implies that the puts function can stop
before it gets to the end of the string.
However, if returning at the first hint of EOF, were the wrong thing
to do, I'm sure somebody else would have said something by now.

--
pete