[BusyBox] [PATCH] size optimization for fdformat.c

[Tito]

On Wednesday 21 January 2004 21:48, you wrote:
> On Wed, 21 Jan 2004 15:29:26 +0000
>
> Tito <farmatito at tiscali.it> wrote:
> > On Wednesday 21 January 2004 08:11, Glenn McGrath wrote:
> >
> > I'm little confused now............
> > you want to make every bb_err function  call check for this var
> > rather than pass a flag to bb_err through the xfunc?
> > if so you have to set this var every time?
> >
> > global_var = DIE|ERROR|WHATEVER;
> > fd = xfopen(.......);
> > global_var= DIE|PERROR;
> > xreadlink(....);
> > and so on.
> >
> > Wouldn't this waste more space than:
> >
> > fd = xfopen(path, mode, DIE|ERROR);
>
> Im not sure, i would have to try test some code, but my gut feeling is
> that lots of assignment operations would be cheaper than adding an extra
> paramater to every xfunction.
>
>
>
> Glenn
on the other side all the error obj files sum up to  about 9k so by using one
function there would be size reduction to balance the overhead of one more arg for every function
and also the number of x and other bb functions would decrease
saving more space. 
 
-rw-r--r--    1 root     root          968 Jan  6 14:19 error_msg_and_die.o
-rw-r--r--    1 root     root          864 Jan  6 14:19 error_msg.o
-rw-r--r--    1 root     root          892 Jan  6 14:19 herror_msg_and_die.o
-rw-r--r--    1 root     root          792 Jan  6 14:19 herror_msg.o
-rw-r--r--    1 root     root          892 Jan  6 14:19 perror_msg_and_die.o
-rw-r--r--    1 root     root          792 Jan  6 14:19 perror_msg.o
-rw-r--r--    1 root     root          808 Jan  6 14:20 perror_nomsg_and_die.o
-rw-r--r--    1 root     root          788 Jan  6 14:20 perror_nomsg.o
-rw-r--r--    1 root     root         1080 Jan  6 14:20 verror_msg.o
-rw-r--r--    1 root     root         1028 Jan  6 14:20 vherror_msg.o
-rw-r--r--    1 root     root         1092 Jan  6 14:20 vperror_msg.o
                                         tot. 9996

and last but not least we would have a more flexible (and easy) api which could
lead to more size optimization.

Tito