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

[Chris Torek]

>Jack Klein <ja*******@spam cop.net> writes:

Given your reasoning, and I see nothing to argue with, optimizing away
the fopen() is a perfectly acceptable application of the as-if rule on
the typical *NIX system, where opening a file leaves no trace in the
system.

In article <87************ @pfaff.stanford .edu>,
Ben Pfaff <bl*@cs.stanfor d.edu> wrote:Most Unix-like kernel, including Linux, also maintain "last
accessed" times. I don't know why you think they don't.

Moreover, if the file name corresponds to a fifo or named-pipe,
simply opening the file for reading can have an effect. In
particular, opening a fifo for reading will unblock a process
that is suspended in an attempt to write to that fifo:

$ mkfifo foo
$ echo hello > foo &
$ jobs
[1] 18389 echo hello >foo
$ echo zog < foo &
$ zog
jobs
[1] 18389 Exit 0 echo hello >foo
[2] 18390 Exit 0 echo zog <foo
$

If you do this in the opposite order, the attempt to read from the
fifo before there are any writers causes the reading program to
hang until someone opens the fifo for writing. Either way it is
obvious that something has happened, even though it is outside the
limited domain of portable C programming.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Barry Margolin]

In article <87************ @pfaff.stanford .edu>,
Ben Pfaff <bl*@cs.stanfor d.edu> wrote:

Jack Klein <ja*******@spam cop.net> writes:

Given your reasoning, and I see nothing to argue with, optimizing away
the fopen() is a perfectly acceptable application of the as-if rule on
the typical *NIX system, where opening a file leaves no trace in the
system.

Most Unix-like kernel, including Linux, also maintain "last
accessed" times. I don't know why you think they don't.

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).

--
Barry Margolin, ba****@alum.mit .edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

[CBFalconer]

"Douglas A. Gwyn" wrote:

Jack Klein wrote:

Then does it follow:
-A compiler for platform A may omit the fopen() call under
the as-if rule
-A compiler for platform B may not omit the fopen() call
...even though the output of the program itself is the same in
either case.

The question is whether there is any way, other than timing,
code size, and other aspects deemed "inessentia l", to detect
whether the code actually performs the call. In a way, this
is all a waste of time, because no compiler that I know of
would optimize away a call to fopen(). Some *would* optimize
away pointless calls to strcmp() etc., in contexts where they
know that a standard library function is involved (so that
its complete semantics are known) and known not to have any
observable effect in the particular case.

Is there some *real* issue lying behind this topic, or is it
just a matter of pedanticism?

I think it is purely pedantic. At any rate there is no telling
what the act of opening a file involves, regardless of system. I
have built systems where the act of opening a particular named
file did some major re-arrangement of the entire i/o system, and
the act of closing that file put it back. This kept the
application proper coding standard and restricted the magic to
file system drivers.

--
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!

[those who know me have no need of my name]

in comp.std.c i read:

On 19 Jan 2004 16:13:33 GMT, Da*****@cern.ch (Dan Pop) wrote in
comp.lang.c:

The only *relevant* side effects of fopen are those specified in the C
standard. Opening a file in read mode doesn't modify the file, therefore it doesn't
count as a side effect, in the context of the C standard.

Given your reasoning, and I see nothing to argue with, optimizing away
the fopen() is a perfectly acceptable application of the as-if rule on
the typical *NIX system, where opening a file leaves no trace in the
system.

actually unices typically do record the time a file was opened. dan might
argue that by itself that isn't sufficient, and in some ways i agree, but
there remains a flaw: there's no way to know whether the FILE object
contains a volatile member or would call the environment since it's
implementation defined.

--
a signature

[Sidney Cadot]

Douglas A. Gwyn wrote:

Jack Klein wrote:

Then does it follow:
-A compiler for platform A may omit the fopen() call under the as-if
rule
-A compiler for platform B may not omit the fopen() call
...even though the output of the program itself is the same in either
case.

The question is whether there is any way, other than timing,
code size, and other aspects deemed "inessentia l", to detect
whether the code actually performs the call. In a way, this
is all a waste of time, because no compiler that I know of
would optimize away a call to fopen(). Some *would* optimize
away pointless calls to strcmp() etc., in contexts where they
know that a standard library function is involved (so that
its complete semantics are known) and known not to have any
observable effect in the particular case.

Is there some *real* issue lying behind this topic, or is it
just a matter of pedanticism?

As for me, it's mostly curiosity about the standard's wording:

"Accessing a volatile object, modifying an object, modifying a
file, or calling a function that does any of those operations
are all side effects"

.... If this would just say "accessing a file" instead of
"modifying a file" the issue would not exist. I wonder if there is a
good reason this particular wording was chosen, and - if not - would
like to see it changed. There's no reason not to strive for perfection
if it is essentially free.

Another thing is that I think the standard's way of defining a "side
effect" (by enumeration of cases) is flawed. This is a bit like defining
mammals as "primates, whales, furry animals, ... (and so on)", which
works fine until you find a platypus.

Surely, there has to be a more generic way of defining a side effect.

Best regards,

Sidney

[Robert Wessel]

Sidney Cadot <si****@jigsaw. nl> wrote in message news:<bu******* ***@news.tudelf t.nl>...

... But that just dismisses one of the possible 'side effects' admitted
by the standard.

Does a fopen(name, "rb") count as 'calling a function that does any of
those operations' ? I think it does; it /has/, at some point, to
interact with the abstract machine's environment, which can only be done
via volatile objects or modifying an object, eventually, somewhere
down the line.

Anyway, we can pick on words (and that's valuable) but if anything, this
shows that the enumeration of 'side effects' as given in the standard
is not exhaustive. Clearly, opening a file (even for reading) interacts
with the outside world, e.g. on unix systems it updates the 'last
accessed' date as pointed out. This is not unambiguously covered by the
standard; if upon literal reading we were to conclude that it isn't
properly covered - well, then the standard needs to be mended on the
next occasion.

The point is that the change your describing (the last accessed date)
is *not* visible to a standard C program, and an implementation could
therefore claim to be conforming even if it removed the open. I think
we'd all agree that such an implementation would have serious QoI
issues.

[Christian Bau]

In article <40************ ***@yahoo.com>,
CBFalconer <cb********@yah oo.com> wrote:

I think it is purely pedantic.
It is purely pedantic because no existing compiler will remove the call
to fopen ().

On the other hand: If you are a compiler writer and you want to remove
this kind of call, then you have to _prove_ that the C Standard allows
it. If you are an application programmer and you want to make sure that
the call is not removed, then you could write

volatile FILE* p = fopen ("my file", "options);

and that will make it damned hard for the compiler writer to optimise
the call away.
At any rate there is no telling
what the act of opening a file involves, regardless of system. I
have built systems where the act of opening a particular named
file did some major re-arrangement of the entire i/o system, and
the act of closing that file put it back. This kept the
application proper coding standard and restricted the magic to
file system drivers.

[Dan Pop]

In <NL************ ********@comcas t.com> "Douglas A. Gwyn" <DA****@null.ne t> writes:

Jack Klein wrote:

Given your reasoning, and I see nothing to argue with, optimizing away
the fopen() is a perfectly acceptable application of the as-if rule on
the typical *NIX system, where opening a file leaves no trace in the
system.

But that is *not* the way that Unix (POSIX) works!
Opening a file *does* have side effects in the environment.

But not according to the C standard (unless you can provide a chapter and
verse). Therefore, removing the fopen() call does not affect the
implementation' s conformance to the C standard (which provides a complete
list of what it considers side effects).

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[James Kuyper]

Jack Klein wrote:
....

Doh! I probably knew that, although I haven't had anything running
Linux in quite a while. It's time of creation that they don't keep
separately, right?

No - seperate times are kept for the creation date, last access, and the
last modification.

[Keith Thompson]

Da*****@cern.ch (Dan Pop) writes:

In <NL************ ********@comcas t.com> "Douglas A. Gwyn"
<DA****@null.ne t> writes:

Jack Klein wrote:

Given your reasoning, and I see nothing to argue with, optimizing away
the fopen() is a perfectly acceptable application of the as-if rule on
the typical *NIX system, where opening a file leaves no trace in the
system.

But that is *not* the way that Unix (POSIX) works!
Opening a file *does* have side effects in the environment.

But not according to the C standard (unless you can provide a
chapter and verse). Therefore, removing the fopen() call does not
affect the implementation' s conformance to the C standard (which
provides a complete list of what it considers side effects).

Side effects include "modifying a file". In a Unix filesystem, a
directory can be treated as a file; so can the physical device
containing the filesystem.

This is admittedly stretching the point.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"