standards; casts to pointers-to-code
Chris Torek
chris at mimsy.UUCP
Fri Sep 16 19:37:11 AEST 1988
In article <225800069 at uxe.cso.uiuc.edu> mcdonald at uxe.cso.uiuc.edu writes:
>Subject: Re: "Numerical Recipes in C" is nonport
Please edit subject lines.
[much deleted]
>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.
[this left in as it is nice in a way, and also shows why his comments
are irrelevant, particularly at this time]
>I don't see why being able to create code and execute it could
>cause the hardware of any machine fits. ...
We already discussed this (remember the Burroughs A-series?).
>... 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.
If I may be permitted to imagine what Dennis Ritchie would say to
this (note that he has NOT said this): `Asking for a cast to compile
into a system call is ludicrous.' If this operation were to be
sanctioned, it should appear as a function call, not a cast. The
function might be a macro that expands to nothing.
>I can conceive of an architecture where it is absolutely impossible
>to have code and data in the same address space ....
You need not merely conceive; such machines already abound.
>But even there it could be done: somehow the system has to get code
>into the code memory ....
Yes. Clearly it *can* be done, and some languages might wish to
require it. C does not now, and C will not when the current X3J11
draft proposed standard becomes an ANSI standard, for it is, as Doug
Gywn has noted, too late (politically speaking) to get a change of this
magnitude accepted, regardless of whether the members of the committee
would think it a good idea.
>... If it were in the C language spec they would have to CHANGE THE
>OPERATING SYSTEM TO MAKE IT WORK or else admit "our ... system ...
>can't have a C compiler".
[inflammatory wording deleted] Just so. Fortunately for those who
might have to say that, it is not in the language.
And on a different tack:
> 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.
Interesting indeed. Have you *read* the draft proposed standard?
Strictly conforming programs cannot require more than 6 (six)
characters in external names. And I do believe you have misquoted
Doug.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: chris at mimsy.umd.edu Path: uunet!mimsy!chris
More information about the Comp.lang.c
mailing list