Undelivered mail

[MAILER%ALASKA.BITNET at CUNYVM.CUNY.EDU]

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 at BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 6866
          for SXJVK at 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 at BRL.ARPA
Sender:       Info-C List <INFO-C at NDSUVM1>
Comments:     Warning -- original Sender: tag was news at sun.uucp
From:         David Hough <dgh%dgh at Sun.COM>
Subject:      ANSI C & Fortran 8x - Expand cpp to partially support generalized
              precision
Comments: To: info-c at brl-smoke.arpa
To:           Vic Kapella <SXJVK at ALASKA>

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
<float.h> 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 at sun.com
UUCP: {ucbvax,decvax,decwrl,seismo}!sun!dhough