Path: utzoo!mnetor!uunet!husc6!mailrus!nrl-cmf!cmcl2!brl-adm!adm!MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU From: MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU Newsgroups: comp.lang.c Subject: Undelivered mail Message-ID: <12276@brl-adm.ARPA> Date: 12 Mar 88 07:51:36 GMT Sender: news@brl-adm.ARPA Lines: 94 Subject: ANSI C & Fortran 8x - Expand cpp to partially support generalized [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 6866 for SXJVK@ALASKA; Fri, 11 Mar 88 22:24 AST Received: by UWAVM (Mailer X1.25) id 4602; Fri, 11 Mar 88 23:23:50 PST Date: Thu, 10 Mar 88 18:26:49 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List Comments: Warning -- original Sender: tag was news@sun.uucp From: David Hough Subject: ANSI C & Fortran 8x - Expand cpp to partially support generalized precision Comments: To: info-c@brl-smoke.arpa To: Vic Kapella I've previously proposed that Fortran 8x include the C preprocessor, and that ANSI C support a limited interface to Fortran-77. While thinking about Bob Corbett's comments about a related Fortran 8x issue, generalized precision, a light flashed (fuse blowing?) and the right thing to do seemed clear. And unlike some of my other comments, this one touches an issue dear to almost every C programmer. So here's what I'll propose to X3J11, modified by the usual insightful reactions I expect you'll post: Comment #26, Section 3.8.8 and 2.2.4.2: predefine generalized precision macros The generalized precision proposal in Fortran 8x is complicated and controversial, yet responsive to a widely- recognized need among implementers of portable numerical software. The same need is most widely felt in the C com- munity as a question like this: what is the most efficient integral type that contains all integers in the range [- 99999,99999] ? Recommendation: To portably declare such types, add the following predefined macros to 3.8.8: __int__(p) is evaluated to the name of the smal- lest signed int type that contains all the signed p-digit integers, i. e. the interval [- (10**p)+1,10**p-1]. __unsigned__(p) is evaluated to the name of the smallest unsigned int type that contains all the p-digit unsigned integers, i. e. the interval [0,10**p-1]. __float__(p,r) is evaluated to the name of the smallest floating-point type that contains exactly all the p-digit signed integers, i. e. all the integers in the interval [-(10**p)+1,10**p-1], and contains 10**r and 10**-r within its range of positive model numbers. __INTEGER__(p) is evaluated to the Fortran name of the type corresponding to __int__(p,r), or to INTEGER is no Fortran compiler is supported. __REAL__(p,r) is evaluated to the Fortran name of the type corresponding to __float__(p,r), or to REAL if no Fortran compiler is supported. __COMPLEX__(p,r) is evaluated to the Fortran name of the complex type whose components are __float__(p,r), or to COMPLEX if no Fortran com- piler is supported. All the precision- and range-dependent macros fail, terminating compilation, if the precision or range requirements can't be met by any supported type. Recommendation: In order that the C pre-processor itself may be written portably, the C run-time library should provide certain corresponding string-valued functions that return the appropriate type for a particular implemen- tation, or a null string on failure. Add the following in to implement the corresponding cpp macros: char * int__ (int p); char * unsigned__ (int p); char * float__ (int p; int r); char * INTEGER__ (int p); char * REAL__ (int p ; int r); char * COMPLEX__ (int p ; int r); David Hough ARPA: dhough@sun.com UUCP: {ucbvax,decvax,decwrl,seismo}!sun!dhough