Re: pure functions

In article <4Gjre.52$X71.31@fed1read07>,
Anonymous 7843 <anon7843@xxxxxxxxxxx> wrote:
>There are also "short term" pure functions like time() and ftell()
>which normally cannot be treated as pure by the compiler, but which
>are nonetheless good candidates for manually hoisting out of tight loops
>in which nothing in the loop resets the date or writes to the file.

That's an interesting idea; I'm not sure that the examples are
the best ones, though.

time() deals in terms of seconds, not in terms of "dates"; any
loop that operates for long enough is going to tick over to a new
second. One could imagine an algorithm that sleep() until just before
an action was to be taken, and then went into a loop polling time()
until the crossover. (The algorithm should, of course, check that
the time() is returning a valid value, for the cases where there is
no real-time clock.)


ftell()... one should look at signals for this one. One cannot
do much within a pure C signal handler routine, but C does not
prohibit implementation extensions such as POSIX.1 . In POSIX.1,
two of the routines that are considered "signal safe" (allowed to
execute them inside a signal handler) are close() and write().
Both of those operate on file descriptors, not on FILE*, but
if I'm interpreting correctly, close() on the file descriptor
"underlying" a FILE* has an effect on the FILE*'s state.

The POSIX.1 1990 language about the connection between file descriptors
and FILE* is not the clearest, so I'm not certain of the exact POSIX.1
proper behaviour in the case of close() and write() on the
underlying descriptors... plausibly the FILE* level wouldn't properly
catch on until the next fseek() [or until sufficient data was
read to exhaust the in-memory buffer, thus calling upon the underlying
read() routine that would notice the end-of-file.] We'd need someone
well versed in POSIX.1 to detail this situation for us.
--
I was very young in those days, but I was also rather dim.
-- Christopher Priest
.

Relevant Pages

  • Re: The Collatz discrete primes!
    ... doubling outside the loop. ... longer on the counter example tree than on the regular tree. ... example being pure or impure but my thought is that the ... smallest odd integer in the counter example path would have ...
    (sci.math)
  • Re: The Collatz discrete primes!
    ... doubling outside the loop. ... longer on the counter example tree than on the regular tree. ... example being pure or impure but my thought is that the ... smallest odd integer in the counter example path would have ...
    (sci.math)
  • Re: Assembly string functions in i386 libc
    ... __pure is a syntax error in the old version of FreeBSD ... This affected everything except libc strlen() since ... change the arg to a literal. ... removes the whole loop if it can see that it doesn't do anything. ...
    (freebsd-arch)
  • Re: Assembly string functions in i386 libc
    ... because __pure prevents more than 1 call ... from the loop. ... This affected everything except libc strlen() since ... basics of these string instructions for a longer time than AMD. ...
    (freebsd-arch)