chris@mimsy.UUCP (Chris Torek) (09/16/88)
In article <225800069@uxe.cso.uiuc.edu> mcdonald@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@mimsy.umd.edu Path: uunet!mimsy!chris