Xref: utzoo comp.unix.wizards:14963 comp.lang.c:16762
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!mcgill-vision!mouse
From: mouse@mcgill-vision.UUCP (der Mouse)
Newsgroups: comp.unix.wizards,comp.lang.c
Subject: Re: C optimizer
Keywords: C pure function optimization
Message-ID: <1464@mcgill-vision.UUCP>
Date: 7 Mar 89 10:08:34 GMT
References: <515@larry.UUCP> <9648@smoke.BRL.MIL> <36034@bbn.COM> <1028@frog.UUCP>
Followup-To: comp.unix.wizards
Organization: McGill University, Montreal
Lines: 35

In article <1028@frog.UUCP>, john@frog.UUCP (John Woods) writes:
> In article <3121@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) writes:
>> Can anyone think of any pure system calls? ioctl(fd, TCGETA, tbuf)?

This really belongs in an OS-specific group.

Let's see....I just ran through the table of syscalls on this system
and getpagesize() and getdtablesize() are the only really pure syscalls
I see there.

> I think that if
> 	(getpid() != getpid())
> ever evaluated to 1, I would be severely astonished.

Signal handlers aside, that's not the point.  If I write

int pid1;
int pid2;

pid1 = getpid();
runinchild();
pid2 = getpid();

then I don't want the compiler to decide that it can rewrite the second
one to "pid2 = pid1;" because getpid() is pure - presumably
runinchild() will fork.

Here's a quick test: a function is pure if it can be replaced with a
memo-function wrapper without changing the semantics.  This is not true
of getpid() or sync(), to pick two examples that are tempting.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu