[uClibc]some bugfixes and my todo list

Erik Andersen andersen at codepoet.org
Tue Dec 12 17:18:25 UTC 2000


On Thu Dec 07, 2000 at 10:03:52AM -0600, Manuel Novoa III wrote:
> 
> 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.

Agreed.  Fixed.

> 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.

This would cause stdio/_stdio_init.o to be linked into every binary,
whether it uses stdio stuff or not.  Granted this is a fairly common
case, but i think the general principle of keeping everything decoupled
should win here...  So fixing the fflush case is good enough I think.

> 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.

I'll look over your strtod patch shortly.

> 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.

Hmm.  Ok.  Though I think e2fs should not rely on libc to define this...

> 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.

Ulp!  Thats a bug in my book.  Fixed.

> -------------------------------------------------------
> 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.

k.

> 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.

I asked Jeff Dionne about this (easy enough since I am working in
the Toronto office this week).  The reason for using float everywhere
was that the soft-float routines for the m68k use float under the hood,
so he wanted to expose that fact at the application level, saving apps
some storage and such.  

In my opinion, if the standards books say double, we should use double
(and perhaps provide alternate float versions for that that want such
things).

> 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.

We'll have to see what sort of size increase it yields.  Also, I think as a 
general rule, anything with float or double in it should be compile time 
disable-able.

> 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?

This is definately in the compile-time-but-disabled-by-default department. 

> 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?

Hmm.  I would like to see the patch to see what you did.

> 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?

Yes, if the glibc headers do it, we want to do it (generally speaking).
I have made a general rule of using glibc 2.1.3 header files in most cases.
Obviously, there are some significant changes in a few places (uClibc uses
a much simplified FILE structure, etc, etc), but my goal is to be 100%
glibc compatible -- for the supported feature set.

 -Erik

--
Erik B. Andersen   email:  andersen at lineo.com
--This message was written using 73% post-consumer electrons--





More information about the uClibc mailing list