[uClibc]some bugfixes and my todo list

[Manuel Novoa III]

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

I thought of that after I sent the original message.  Agreed.
 
> > 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...

It isn't a problem for me to handle this at the e2fsprogs level.  I can patch
it there easily enough.  Let me know how you want to handle it.
 
> > 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).

I'm of the opinion that if you want a nonstandard float version, then it should
have a nonstandard name... something like strtof instead of strtod.  If you're
writing new code, it isn't a problem.  If you're porting code, you could do
something like
#define double float
#define strtod strtof
and if that causes a problem, you probably have other floating point issues to
deal with as well.

If you really want transparency, I suppose you could have different versions in
the architecture-specific directories and provide the appropriate prototypes
based on the arch.

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

I'm coming along with it.  Minimal size is the primary goal.  Of course, I
intended it to be build-time selectable.
  
> > 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.

I'll clean it up and get it to you soon.

Manuel