From: utzoo!decvax!ittvax!swatt Newsgroups: net.unix-wizards Title: Re: float/double in C Article-I.D.: ittvax.434 Posted: Thu Sep 9 10:00:04 1982 Received: Fri Sep 10 03:47:25 1982 References: research.295 Note that the float==>double (always) rule, in its guise of char==>int (always), hurts the 8-bit micros as well (remember them?). The 8080 is a particularaly nasty example. Someone at John Fluke in Seattle took and modified the Whitesmiths 8080 compiler to treat type "char" as a real data type such that operations only involving chars were NOT converted to int. This of course had the effect of adding an extra width of argument passed on the stack, but the gains in efficiency more than made up for the nuisance. I think this is what prompted Bill Plaugher's comment that "8-bit micros are below C level". On the VAX, you have short int==>int (always) as well. I have often thought a reasonable rule could be: In mixed type expressions, all sub-expressions are converted to the type with the greatest precision before the expression is evaluated. If all sub-expressions are of the same type, the evaluation is carried out without conversions, if convenient for the host machine. In no case is the precision of the result any LESS than the precision of any of the sub-expressions. Thus in the examples Dennis Ritchie mentioned: double a; float b,c; a = b + c; The rule would force conversion of "b" and "c" to double before the addition and assignment. However if "a" were also of type float, no conversion would take place. The difficulties with pdp-11 could be handled under the "if convenient ..." clause. The problems with library routines, I submit, are NOT best handled by limiting the number of types functions can return, but by knowing exactly what each function actually does return. I think the rules for the linker do not imply a reference if one just declares: double sin(); but doesn't actually use the function (I may be wrong). If this is the case, good practice should encourage people to include a file declaring the types of the functions they are getting from the library. Someone (I think Mark Horton) suggested having function types default to "void" instead of "int". Note that you HAVE to correctly declare pointers to floating-point types because of the issue of correct storage width. I think in some machines the address of a float type is not the same as the address of a double type, so that if you pass the address of a double type and call it the address of a float type, you will get incorrect results (if this isn't true now, you can bet it will be sooner or later). Dennis also mentioned a bug fix involving unnecessary double<==>float conversions; I think a similar bug also degrades int<==>unsigned short operation on the VAX -- look at driver code to manipulate UNIBUS registers. Is this bug easily identified and fixed? - Alan S. Watt