The ecvt(), fcvt(), and __dtoa() routines were generally
rewritten to address the problem of printing floating point
numbers (they sometimes came out wrong, especially representations
of zero).
__dtoa was written from the description in the BSD sources (note
that the comment of it being "like ecvt/fcvt other than truncating
trailing zeros") is not quite accurate where it comes to the rve
pointer or the printing of zero values. __dtoa is still expected
to be wrong for any modes other than 2 and 3, however those modes
are not used by anything in libc yet. Fix them when they pop up.
BSD has not ecvt/fcvt routines, so these have been written based
on the man page and observed behavior of the Linux implementation.
There is no gcvt yet.
- changed trenco.myrias.com to trenco.gno.org
Makefile:
- install the GNO version of the man page instead of the
BSD version
- install into /usr/bin vice /bin
Explicitly specify the output file in default compilation rules.
This is needed specifically for the GNO builds, but is also
relevent to other uses of dmake.
- the rez fork rules is now in one of the *.mk files; don't
include it here
- make sure the contrib.h header gets installed
libcontrib.rez:
- added the build date
Added $(LOCAL_SETUP) to the list of build targets, before
$(LIBTARGET). LOCAL_SETUP should be set in the lower makefiles
if there is a target which must be made prior to the main
compilation.
- abbreviated some macros
- removed the -v compilation flag (it can be added from the make
command line if necessary)
- use single colons in additional dependancies
sed.desc:
- expand the description a bit.
Added MACGEN and MACGEN_FLAGS macros.
binrules.mk:
Added a (normally empty) macro "LOCAL_SETUP" to the build target.
If a utility needs a special target to be done prior to the
main build, then it sets this macro to be that special target(s).
paths.mk:
Added some comments on the OBJ_DIR directory.
- Fixed a problem reported by Derek where stack trashing
was happening once an EOF was reached. This was actually
only one example of a class of problems; any time __svfscanf
returned before filling all the requested arguments, va_arg
was left uncalled for some set of arguments. This has been
fixed by adding a "stack cleanup" section to the code where
va_arg is called once for each remaining argument.
- The __svfscanf routine still had large arrays on the stack.
These have been changed to static storage class. There is
currently an assert in place to assure that recursion isn't
happening since I didn't have the chance yet to verify in
detail the control flow here. This assert (and the related
use of the "recursing" variable) can be removed after such
a verification.
gdr-ftp
tribby
taubert