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

[Johan Lindh]

Sidney Cadot wrote:

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

I'll take a stab at this...

Since fopen() is a function (15.2), it may therefore have side effects.
Optimizing it away would therefore be an error.

Perhaps the OS it's running on starts up a pot of coffee if someone
opens the 'somefile' file for reading, and that's the intended effect.

/J

[Tristan Miller]

Greetings.

In article <bu*********@ne ws.tudelft.nl>, Sidney Cadot wrote:

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.

I don't know what the standard says, but from an implementation point of
view it might make sense not to optimize the fopen() away. Many file
systems maintain a "last accessed" timestamp for files; therefore, the
seemingly useless fopen() does indeed modify the environment.

Regards,
Tristan

--
_
_V.-o Tristan Miller [en,(fr,de,ia)] >< Space is limited
/ |`-' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= <> In a haiku, so it's hard
(7_\\ http://www.nothingisreal.com/ >< To finish what you

[Dan Pop]

In <40********@new s.wineasy.se> Johan Lindh <jo***@linkdata .getridofthis.s e> writes:

Sidney Cadot wrote:

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.
The as-if rule basically says that any optimisation/pessimisation is
allowed, as long as the *specified* output of the program is not affected.
Consider two programs:

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

/*** b.c ***/
int 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 ?
Yes, because both programs generate the same output, according to the
description of the abstract machine. Opening a file in read mode and
closing it (if the opening succeeded) does not generate any output.
I'd welcome a reference from the standard.

I'll take a stab at this...

Since fopen() is a function (15.2), it may therefore have side effects.
Optimizing it away would therefore be an error.

Perhaps the OS it's running on starts up a pot of coffee if someone
opens the 'somefile' file for reading, and that's the intended effect.

The only *relevant* side effects of fopen are those specified in the C
standard.

Here is the standard reference:

5.1.2.3 Program execution

1 The semantic descriptions in this International Standard describe
the behavior of an abstract machine in which issues of optimization
are irrelevant.

2 Accessing a volatile object, modifying an object, modifying a
file, or calling a function that does any of those operations
are all side effects,11) which are changes in the state of the
execution environment. Evaluation of an expression may produce
side effects. At certain specified points in the execution
sequence called sequence points, all side effects of previous
evaluations shall be complete and no side effects of subsequent
evaluations shall have taken place. (A summary of the sequence
points is given in annex C.)

3 In the abstract machine, all expressions are evaluated as
specified by the semantics. An actual implementation need not
evaluate part of an expression if it can deduce that its value is
not used and that no needed side effects are produced (including
any caused by calling a function or accessing a volatile object).

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.

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

[Sidney Cadot]

Cross-posted to comp.std.c from a discussion in comp.lang.c; feedback
welcomed.
Dan Pop wrote:

In <40********@new s.wineasy.se> Johan Lindh <jo***@linkdata .getridofthis.s e> writes:

Sidney Cadot wrote:

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.

The as-if rule basically says that any optimisation/pessimisation is
allowed, as long as the *specified* output of the program is not affected.

Consider two programs:

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

/*** b.c ***/
int 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 ?

Yes, because both programs generate the same output, according to the
description of the abstract machine. Opening a file in read mode and
closing it (if the opening succeeded) does not generate any output.

I'd welcome a reference from the standard.

I'll take a stab at this...

Since fopen() is a function (15.2), it may therefore have side effects.
Optimizing it away would therefore be an error.

Perhaps the OS it's running on starts up a pot of coffee if someone
opens the 'somefile' file for reading, and that's the intended effect.

The only *relevant* side effects of fopen are those specified in the C
standard.

Here is the standard reference:

5.1.2.3 Program execution

1 The semantic descriptions in this International Standard describe
the behavior of an abstract machine in which issues of optimization
are irrelevant.

2 Accessing a volatile object, modifying an object, modifying a
file, or calling a function that does any of those operations
are all side effects,11) which are changes in the state of the
execution environment. Evaluation of an expression may produce
side effects. At certain specified points in the execution
sequence called sequence points, all side effects of previous
evaluations shall be complete and no side effects of subsequent
evaluations shall have taken place. (A summary of the sequence
points is given in annex C.)

3 In the abstract machine, all expressions are evaluated as
specified by the semantics. An actual implementation need not
evaluate part of an expression if it can deduce that its value is
not used and that no needed side effects are produced (including
any caused by calling a function or accessing a volatile object).

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.

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

Best regards,

Sidney

[Jack Klein]

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

In <40********@new s.wineasy.se> Johan Lindh <jo***@linkdata .getridofthis.s e> writes:

Sidney Cadot wrote:

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.
The as-if rule basically says that any optimisation/pessimisation is
allowed, as long as the *specified* output of the program is not affected.
Consider two programs:

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

/*** b.c ***/
int 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 ?
Yes, because both programs generate the same output, according to the
description of the abstract machine. Opening a file in read mode and
closing it (if the opening succeeded) does not generate any output.
I'd welcome a reference from the standard.

I'll take a stab at this...

Since fopen() is a function (15.2), it may therefore have side effects.
Optimizing it away would therefore be an error.

Perhaps the OS it's running on starts up a pot of coffee if someone
opens the 'somefile' file for reading, and that's the intended effect.

The only *relevant* side effects of fopen are those specified in the C
standard.

Here is the standard reference:

5.1.2.3 Program execution

1 The semantic descriptions in this International Standard describe
the behavior of an abstract machine in which issues of optimization
are irrelevant.

2 Accessing a volatile object, modifying an object, modifying a
file, or calling a function that does any of those operations
are all side effects,11) which are changes in the state of the
execution environment. Evaluation of an expression may produce
side effects. At certain specified points in the execution
sequence called sequence points, all side effects of previous
evaluations shall be complete and no side effects of subsequent
evaluations shall have taken place. (A summary of the sequence
points is given in annex C.)

3 In the abstract machine, all expressions are evaluated as
specified by the semantics. An actual implementation need not
evaluate part of an expression if it can deduce that its value is
not used and that no needed side effects are produced (including
any caused by calling a function or accessing a volatile object).

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.

It would not be acceptable on a Win32 system, and quite possible other
systems. Win32 keeps multiple time values for files in the file
system, one of which is the last accessed time. An open of an
existing file followed by a close without reading or writing will
modify the file system's last access time, which does modify the file
even though it does not change the contents.

[also cross-posted to comp.std.c]

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Ben Pfaff]

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.
--
int main(void){char p[]="ABCDEFGHIJKLM NOPQRSTUVWXYZab cdefghijklmnopq rstuvwxyz.\
\n",*q="kl BIcNBFr.NKEzjwC IxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+= strchr(p,*q++)-p;if(i>=(int)si zeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}

[Jack Klein]

On Mon, 19 Jan 2004 20:20:42 -0800, Ben Pfaff <bl*@cs.stanfor d.edu>
wrote in comp.std.c:

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.

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?

In any case the real question is:

Given:

-Compilers that generate executables for platforms A and B

-Platform A does not change the externally visible state of its file
system in any way when an existing file is opened and closed with no
actual access in between.

-Platform B does change the externally visible state of its file
system in some way (e.g., updating a last accessed time stamp field
associated with the file) under the same circumstances.

-The following program:

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

....where the parameters passed to fopen() are such that the call
succeeds.

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.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Douglas A. Gwyn]

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.

[Douglas A. Gwyn]

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?