Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!quanta.eng.ohio-state.edu!kaa.eng.ohio-state.edu!rob
From: rob@kaa.eng.ohio-state.edu (Rob Carriere)
Newsgroups: comp.lang.c
Subject: Re: C optimizer
Message-ID: <1416@quanta.eng.ohio-state.edu>
Date: 17 Feb 89 06:47:57 GMT
References: <1398@quanta.eng.ohio-state.edu> <2008@goofy.megatest.UUCP>
Sender: news@quanta.eng.ohio-state.edu
Reply-To: rob@kaa.eng.ohio-state.edu (Rob Carriere)
Organization: Ohio State Univ, College of Engineering
Lines: 27

In article <2008@goofy.megatest.UUCP> djones@megatest.UUCP (Dave Jones) writes:
>From article <1398@quanta.eng.ohio-state.edu>, by rob@kaa.eng.ohio-state.edu 
(Rob Carriere):
>> What seems to be missing is the idea that sleep *does* modify
>> something, namely time.  So formally speaking, your compiler should
>> consider sleep to have a side effect on a variable called __time.  If
>> you do that, there's no problem.
>Huh?? 
>% nm a.out | grep __time
>Know what I mean?

Perfectly.  Do you know what I mean?  Note the phrase ``formally
speqaking'' in the above and insert ``for example'' after ``called''.

>On a time-shared system (such as Unix), does every instruction have
>a side effect on a variable called __time?

Of course.  And on any non-time shared system as well.  The poster to
whom I was replying considered the passage of time a side effect.  If
that is the case, you'd bloody well better model it as part of the
system state.

>Gimme a break.  (Or at least a sleep(300).)

Breaks are free() this week :-)

SR