"Numerical Recipes in C" is nonport

[Doug Gwyn]

In article <225800065 at uxe.cso.uiuc.edu> mcdonald at uxe.cso.uiuc.edu writes:
>>	Generate code in an array.
>>	Jump to the beginning of the array. *
>It is certainly possible to design machine\compiler combinations that
>prevent this. I call them "totalitarian " or "Stalin" operating systems.
>Apparently ANSI C does not prohibit this behaviour: a fatal flaw
>in the ANSI standard. IF you can't do this, an entire class of programs
>becomes absolutely impossible: incremental compilers. It would prohibit
>a Turbo C or Quick C clone, for example. All of my programs I have designed
>for teaching chemistry and physics wouldn't work.

I'm getting a bit tired of talk about "fatal flaws" in the proposed
ANSI C standard from people who don't understand the goals and
constraints under which such a standard is developed.  It is simply
NOT FEASIBLE for a global C standard to dictate characteristics of
an implementation environment such as the ability to (somehow) switch
the thread of execution into a process's data space.  The proposed C
standard does not prohibit an implementation from offering support
for such a feature, but it also does not require such support.
Any application that depends on such a feature, or on dynamic linking,
communication with coprocesses, or other specific techniques for
run-time creation and execution of machine instructions, is already
inherently nonportable.  It is not the job of a C standard to render
already nonportable code suddenly, magically portable.

Feel free to do anything that happens to work at the moment on your
particular system.  Just be aware that it may not work elsewhere or
elsewhen, and please have the good sense not to blame this on
people who have no direct control over that aspect of reality.