"Numerical Recipes in C" is nonport

[mcdonald at uxe.cso.uiuc.edu]

In article <225800065 at uxe.cso.uiuc.edu> mcdonald at uxe.cso.uiuc.edu 
(that's me folks) 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.

The usually sane Doug Gwyn replies:

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

I don't care one whit about what the goals and constraints of X3J11
(or X3J3 for that matter) ARE. I care about what they OUGHT to do.
I don't see why being able to create code and execute it could
cause the hardware of any machine fits. I can see how it might make
a compiler vendor have fits if a cast of a data pointer to a code pointer
wasn't simply a no-op, as it is on most sane machines. On the
vast majority of machines it IS either a no-op, or , for example
in OS/2, there is a simple system call that turns a data pointer to
a code pointer which you can call. The cast would simply have to call
the operating system. I can conceive of an architecture where it
is absolutely impossible to have code and data in the same address 
space: say a physically different memory. But even there it could
be done: somehow the system has to get code into the code memory,
prehaps the only way being to write it to disk and read it out. In
that case the run time library has to write out the data, and read
it back in. I don't accept the argument that "our operating
system doesn't allow user programs to do that". If it were in the
C language spec they would have to CHANGE THE OPERATING SYSTEM TO
MAKE IT WORK or else admit "our operating system is so broken that
we can't have a C compiler". I want it put in the language definition
so that systems that can't do it are made to say to all the world
"Look at me, I'm the big bright computer of the future, I'll tell
you how great this hotshot new protection scheme is, it's
so great that I'm terminally unable to offer a C compiler to my 
users (if there are any)." I want the C standard to essentially
force vendors to fix their machines.
   Dynamic linking, coprocessors, etc. really ARE operating system
issues, and outside C. I am less than happy over the raw-terminal-io
discussion going on in another comp.lang.c thread: I think that
a portable way to get raw io MIGHT be possible, and should be
thought about. But the issue there is PORTABILITY, not IMPOSSIBILITY.
 
   I find it quite interesting to compare X3J11 to X3J3. X3J3 has
been known to give the same argument that Gwyn uses, to wit, 
"it would discombobulate one vendor" to argue against adding features
to Fortran, when the very same features are ALREADY in C! Among
these are bit operations ( | & ^ in C) and external names longer than
6 (six) characters.  

Doug McDonald