minow@thundr.dec.com (Martin Minow THUNDR::MINOW ML3-5/U26 223-9922) (01/10/88)
Commenting on the ongoing Standard discussion, Doug Gwyn asks for "good syntax for a built-in exponentiation operator." I don't see where one is needed. If <stdarg.h> contains #define pow(x,y) _pow(x,y) the syntax analyser/translator can recognize the _pow() and perform any in-line operations it deems appropriate. In his discussion on VMS's need to return different values to the operating system than on Unix, may I point out that the problem predates VMS -- C compilers were available on several PDP-11 operating systems, including RSX-11M and RT11, before the development of Vax C. There were (at least) three sources for such compilers, including the public-domain Decus C, first published in 1978. I have been writing portable C applications for at least 10 years. To solve the exit() argument problem, I include the following in my programs: #ifdef vms #include <ssdef.h> #include <stsdef.h> #define IO_SUCCESS (SS$_NORMAL | STS$M_INHIB_MSG) #define IO_ERROR SS$_ABORT #endif /* * Note: IO_SUCCESS and IO_ERROR are defined in the Decus C stdio.h file */ #ifndef IO_SUCCESS #define IO_SUCCESS 0 #endif #ifndef IO_ERROR #define IO_ERROR 1 #endif When I revise the Decus C toolkit to adapt it to the Ansi Standard, fixing exit() values will be the least of my worries. From Doug's posting: >>This is apt, since VMS caused the problem in the first place. >Actually, I agree with this, but since we found a solution that the >VMS folk could live with, why not stick with it. I would claim that the problem was caused, not by a specific operating system, but by people who put constant values into their programs. Kernighan and Plauger (A Manual of Programming Style) warned against this *many* years ago. That the developers of Unix didn't heed their collegues' warnings doesn't make them less relevant. Martin Minow minow%thundr.dec@decwrl.dec.com decvax!decwrl!dec-rhea!dec-thundr!minow The above does not reflect the position of Digital Equipment Corp.
ok@quintus (Richard A. O'Keefe) (07/11/88)
I have received e-mail taking me to task for claiming that pow() in C is
similar to ** in Fortran. My correspondent was apparently labouring under
the impression that pow(x,y) was the equivalent only of REAL(x)**REAL(y).
The System V Interface Definition explicitly states that pow(x, y) is
valid for negative x provided that "y is an integer". Judging by the
versions I have used, pow() behaves *as if* it did
if there is an integer n such that (double)n == y
return x**n /* e.g. pow(-2.0, 3.0) = (-2.0)**3 = -8.0 */
else
return exp(log(x)*y);
While I personally think this is an ugly hack and that it would have been
better to have two functions, this does seem to be the way things are in UNIX.
The question is: what does the dpANS say? Is this special-casing for
exponents which happen to approximate integers required, forbidden, allowed?