dgh%dgh@Sun.COM (David Hough) (03/11/88)
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@sun.com
UUCP: {ucbvax,decvax,decwrl,seismo}!sun!dhoughswarbric@tramp.Colorado.EDU (Frank Swarbrick) (03/12/88)
I don't know if you'd take this into concideration, but Turbo C already
uses __int__() for a general interrupt.
(i.e. #define geninterrupt(i) __int__(i) I have no idea why they have
this, but they do.)
Frank Swarbrick (and his cat)
swarbric@tramp.UUCP swarbric@tramp.Colorado.EDU
...!{hao|nbires}!boulder!tramp!swarbric
"Welcome back my friends to the show that never ends..."flaps@dgp.toronto.edu (Alan J Rosenthal) (03/12/88)
[In editing David Hough's article below, I have taken representative paragraphs. -ajr] In article <44981@sun.uucp> dgh%dgh@Sun.COM (David Hough) writes: >Comment #26, Section 3.8.8 and 2.2.4.2: predefine generalized precision macros >... >__int__(p) is evaluated to the name of the smallest signed int type >that contains all the signed p-digit integers, i. e. the interval >[-(10**p)+1,10**p-1]. >... Useable but not very useful. Also not sufficiently well defined. What is its value for p > log10(LONG_MAX)? Also, your macros are very different from all other preprocessing macros in that they don't simply substitute to a string (with possible replacements from the arguments). Also also, nowhere else does the preprocessor know about names of types. >__INTEGER__(p) is evaluated to the Fortran name of the type corresponding >to __int__(p), or to INTEGER if no Fortran compiler is supported. >... Since no Fortran compiler is supported by the ANSI C standard, you can just say "INTEGER". The C standard does not mandate a separate preprocessor, nor should it. That would be the domain of a Preprocessor Standard. It seems like that is what you are proposing. Perhaps you should write one, or get someone else to write one. ajr -- If you had eternal life, would you be able to say all the integers?
terry@wsccs.UUCP (terry) (03/20/88)
In article <4804@sigi.Colorado.EDU>, swarbric@tramp.Colorado.EDU (Frank Swarbrick) writes: > I don't know if you'd take this into concideration, but Turbo C already > uses __int__() for a general interrupt. > (i.e. #define geninterrupt(i) __int__(i) I have no idea why they have > this, but they do.) The response above was to an article suggesting __int__(999999) yeild the smallest integer/char/long/etc. data type that could contain the value 999999, and similar tricks, thus allowing you to declare only what you need to declare. Not to be rude, but I don't think an interrupt routine on a severly localized product based 1) on IBM DOS BIOS architecture, and 2) on 8086/80x86 calling conventions based on register push order _should_ be considered. The __int__(i) function is peculiar to Turbo C, which can not be demonstrated to be K&R compatable as far as the book "The C Programming Language" has defined pre-initialization of declared (non-external) global variables not explicitly set to a value to have a value of 0. Turbo C does not do this. Neither does it correctly treat local non-initialized static variables. It is arguably not C. (I'll argue more, if you want :-}). The function you talk about came as a result of the IBM-PC interrupt calling sequence not being the same as the "normal" oprcedure calling sequence... ie: PUSHing/POPing of registers on function entry/exit. It is NOT standard to any other C, and while it lets you do nifty things on DOS, such as memory resident pink-pad replacements, it doesn't do a thing for UNIX/VMS systems, which already have a standard method of catching catchable interrupts called 'signal()'. You can generate interrupts, too. Nope, I think we can safley ignore Turbo C when considering standardization of C across machines. PS: Personally, I support the __<your_type_here>__(<sized object>) declarative ...it's pretty useless unless you are on a memory-limited machine, since you might as well make it huge elsewhere if you can't remember what it should be. | Terry Lambert UUCP: ...{ decvax, ihnp4 } | | @ Century Software : ...utah-cs!uplherc!sp7040!obie!wsccs!terry | | SLC, Utah | | These opinions are not my companies, but if you find them | | useful, send a $20.00 donation to Brisbane Australia... | | 'There are monkey boys in the facility. Do not be alarmed; you are secure' |