Should I convert FORTRAN code to C?
T. William Wells
bill at proxftl.UUCP
Sun Jun 26 20:53:29 AEST 1988
In article <8098 at brl-smoke.ARPA>, gwyn at brl-smoke.ARPA (Doug Gwyn ) writes:
) In article <3946 at pasteur.Berkeley.Edu> faustus at ic.Berkeley.EDU (Wayne A. Christopher) writes:
) >The best reason NOT to allow a compiler to expand standard functions in-line
) >is that you can't substitute your own to fix a bug in the standard version.
) >I've had to do this a number of times with bug-prone functions like floor()
) >(too many versions round towards zero instead of down).
)
) NO NO NO -- Don't do this!
)
) Assuming for the sake of argument that some implementation has a floor()
) function like that, it is quite possible that some of the other math
) library routines actually depend on that behavior. If you change it,
) you will break other routines in possibly subtle ways.
)
) A much better solution to this particular problem would be:
)
) #define Floor my_floor /* or "floor", if it works right */
) extern double Floor(double);
)
) /* ... use "Floor" instead of "floor" ... */
)
) double my_floor(register double x) /* adjust for floor() bug */
) {
) extern double floor(double); /* from math library */
) register double xf = floor(x);
)
) return x >= 0 ? xf : x == xf ? x : xf - 1;
) }
)
) Also report the floor() bug to the library implementor.
I agree with all of that, except one point. I would just take the
original code which uses floor and place a #define floor my_floor
in a configuration file surrounded by #ifdef BUGGY_FLOOR/#endif.
I'd then put my_floor in a file in a file for configuration
dependent code.
I would only code a routine with the name my_floor if I wanted to
write a routine similar to floor but with some minor differences.
More information about the Comp.lang.c
mailing list