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