[uClibc]some bugfixes and my todo list

[Manuel Novoa III]

Erik,

Below a few bugfixes -- not a patch, but they're not exactly complex either.

Also, there's a list of some issues I plan to work on.   Please look over this
list and let me know what you think.

Manuel

-------------------------------------------------------
BUGFIXES:

1)  stdio/stdio.c: function "fflush" should begin with an "Inline_init;"
statement.  This also ensures that I/O is initialized by setbuf or setvbuf.
Question: why not just initialize I/O in sysdeps/linux/common/libc_init.c and
get rid of all these Inline_init statements in stdio.c?  I'd be happy to do
this if you like.

2) stdlib/strtod.c: the line "exponent++;" in the exponent parsing should
actually be "nptr++;".  Changes I plan to make include float->double and proper
error handling with the endptr arg.

3) include/features.h: I had to add a "#define __KERNEL_STRICT_NAMES" line in
order to build the e2fs progs.  Actually, I did what glibc does and added the
following:
	#undef  __KERNEL_STRICT_NAMES
	#ifndef _LOOSE_KERNEL_NAMES
	# define __KERNEL_STRICT_NAMES
	#endif
You may want to handle this differently though.

4) include/stdlib.h:  Not exactly a bug, but the top of the file looks like
	#include <features.h>
	#include <sys/types.h>
	#include <limits.h>

	#ifndef __STDLIB_H
	#define __STDLIB_H
and the includes should be moved after the the define.

-------------------------------------------------------
ISSUES I plan to work on

1) stdio/printf.c: Right now the format string parsing accepts some illegal
formats without error.  I plan to do a cleanup.

2) general floating point issues: Change floats to doubles when they should
be.  This includes cleaning up math.h and fixing strtod for proper error
handling.

3)stdio/printf.c: To aid in porting other programs, I plan to add (build-time
feature) floating point support for printf.  Code size is the most important
concern for me here.  Support should be good enough for most applications.

4) stdio/printf.c: e2fsck needed printf to support "long long"'s.  I added it in
my tree, but wanted to know if this is a problem for any arch's that uClibc
might be targeted for.  Should this be a build-time feature?

5) misc/time/tm_conv.c: I have a patch for (rudimentary) support the TZ
environment variable.  I don't worry about daylight savingstime... I just use
the offset given from TZ=XXX[+-]##XXX.  Is this something you want in uClibc? 
As a build-time feature?

6) Basically everything defined in linux/stat.h is also defined
ininclude/sys/stat.h.  There is a test in linux/stat.h to avoid this if using
glibc.  There are several other linux header files that check for glibc as
well.  Should uClibc impersonate glibc w.r.t. these header files?