Bug in cut

[Richard Hoyle]

On Nov 21, 2007 7:55 AM, Denys Vlasenko <vda.linux at googlemail.com> wrote:
> On Tuesday 20 November 2007 22:12, Richard Hoyle wrote:
> > Hi,
> >
> > There seems to be a bug in the cut command.  Try this in _install/bin
> >
> > ./echo fred | ./cut -b1 | ./cat -
> >
> > This patch seems to fix the problem.
> >
> > --- cut.c.org   2007-11-10 01:40:51.000000000 +0000
> > +++ cut.c       2007-11-21 05:57:03.000000000 +0000
> > @@ -284,5 +284,5 @@
> >         }
> >         if (ENABLE_FEATURE_CLEAN_UP)
> >                 free(cut_lists);
> > -       return EXIT_SUCCESS;
> > +    fflush_stdout_and_exit(EXIT_SUCCESS);
> >  }
> >
> > Thanks for BusyBox and making it GPL'd software.
> >
> > All the best,
>
> Please specify your version of busybox and attach your .config.
> --
> vda
>

Hi Denys,

Firstly, I must apologise for posting prematurely.  It seems this
has all been commented on before. And I guess this is not really a
bug.

I'm using busybox-1.8.1, but the 'bug' manifested itself in
earlier versions (certainly 1.7.2).  And was commented on here,
amongst other places:

http://www.busybox.net/lists/busybox/2006-October/025157.html

The problem, of course, is that I was building statically, against
glibc.  A beta version of my distro simply comments out the
warning in applets/applets.c, and builds without getting rid of
--gc-sections option to ld.  I blindly assumed it was OK, and that
warning was somehow historic.

Anyway, I removed all --gc-sections lines out of scripts/trylink,
and that fixed the problem with the standard cut.

Questions:

a) Is removing the --gc-sections lines from scripts/trylink now
   the recommended way to do this (if one must)?

b) Why do some utils finish with a (indirect) call to
   fflush(stdout), and others do not?  Wouldn't it be better to
   call fflush in all utils or call fflush in none?

c) Might it not be a good idea to update the warning in applets.c
   re the location of --gc-sections?

d) The warning in applets.c contains:

   "Note that glibc is unsuitable for static linking anyway"

   Most of busybox seems to work just fine being statically linked
   against glibc.  What other issues are you aware of that impact
   on static builds against glibc?

Thank you for your patience with this.

All the best,

===Rich