On Tuesday 10 June 2008 07:23, Robin Getz wrote: > If you are talking about deviating from the "just recompiling" mantra - even > to handle corner case error conditions, I need to rethink using uClibc going > forward. > > The expectation is functionality as specified in IEEE Std 1003.1 > http://www.opengroup.org/onlinepubs/009695399/
I don't see the point to repeat again that in this case, in my opinion, it does not matter. We are simply disagreeing on this. I have no problem with sometimes having a minority opinion. Since majority opinion seems to be to not use malloc, it can be reverted. > It seems like more and more functions that you are modifying are deviating > from the standard, defined interface. More and more? I don't remember changing anything else in "standard-deviating" way, modulo bugs (that getpot embarrasment). Other changes were falling into two categories: 1. Reduce memory usage ("smallints") 2. Fix three-year old bugs from uclibc bugzilla and failing uclibc testsuite. > I always thought the project goals > were: > 1) standard functionality > 2) minimum size > > Have things changed so it is the other order? Changing the project goals is > something I would not support. Perhaps I am personally trying to push "minimum size" more because of busybox. It's an itch for me when I see 70k of memory wasted. -- vda _______________________________________________ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc