Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!linus!philabs!cmcl2!seismo!brl-tgr!gwyn
From: gwyn@brl-tgr.ARPA (Doug Gwyn )
Newsgroups: net.lang.c
Subject: Re: ANSI C suggestions
Message-ID: <5399@brl-tgr.ARPA>
Date: Fri, 19-Oct-84 16:11:06 EDT
Article-I.D.: brl-tgr.5399
Posted: Fri Oct 19 16:11:06 1984
Date-Received: Sat, 20-Oct-84 07:19:29 EDT
References: <228@boulder.UUCP> <4460@utzoo.UUCP> <205@rlgvax.UUCP>
Organization: Ballistic Research Lab
Lines: 27

> > ... Note also that constants are still "double" unless explicitly cast
> > to "float", which is a nuisance (the alternative was nightmarish problems
> > in deciding the type of a floating-point constant).  Not ideal, but workable.
> 
> I presume the FORTRAN alternative (it's single precision unless specified
> with an exponent whose exponent character is 'd', not 'e', like
> "3.1415926535d0") was rejected for compatibility reasons; intuiting the
> type from the length of the string or somesuch is, I agree, nightmarish.
> The only alternative is to require it to be stated explicitly somehow;
> the question is whether the default should be "double" or "float".  ("long"
> constants already require the length to be specified explicitly, by a
> trailing "L".)

I see no real problem with C floating-point constants continuing to be
interpreted as double-precision.  Examples:

#define PI	3.14159etc.	/* who knows how it's going to be used? */

float	value = 1.5;		/* compiler can figure this out */

double	value = (float)1.5;	/* throwing away precision for some reason */

float	value = (float)atan2( 0.5, 1.0 );	/* args must be doubles */

Also, remember that such constants are currently doubles and any change
needs to preserve this property to avoid breaking existing correct code.
(float) is simple, unambiguous, and seldom explicitly required.