Review of the last few applied patches...
Rob Landley
rob at landley.net
Fri May 19 15:25:42 PDT 2006
On Friday 19 May 2006 2:14 pm, Bernhard Fischer wrote:
> >I just hand edited the duplicate strings output to remove the false
> > positives, and there's 615 left. (See attachment.)
>
> do you mean --merge-all-constants ?. Sounds a bit dangerous and
> doesn't seem to gain much:
> $ size busybox_old busybox_unstripped
> text data bss dec hex filename
> 848951 9100 645216 1503267 16f023 busybox_old
> 848735 9100 645216 1503051 16ef4b busybox_unstripped
>
> I think we should try to (manually) reuse as much strings as possible
> anyway.
A) If it really is constant it doesn't _sound_ dangerous.
B) The file I attached was 13k, which is noticeably larger than 200 bytes. :)
> >15128: I'd have removed it.
>
> done.
Woot.
> >15126: Fine. Should add the llist note to the TODO. In fact I should go
> >through the todo thread from last month and add all the minor todo items
> >to the TODO.
>
> Please do.
I have a todo item to collate the todo lists. This is _sad_.
> >15124: What is strings.h needed for again? Does this #include make a
> > warning
>
> str{,n}casecmp()
>
> >go away, or is some future "remove unnecessary #includes" pass going to
> > just undo this again? There's no rationale as to _why_ this was
> > included. Maybe it was in the email.
>
> It was in the checkin message for the -stable branch.
Under linux, #include <string.h> defines strcasecmp(), which is why we didn't
see a warning. You don't need strings.h. In fact having a separate
"string.h" and "strings.h" at all strikes me as deep and abiding stupidity on
the part of somebody upstream. There's no _CHANCE_ to keep those straight in
one's head, and no obvious reason to try. (Hence linux including one from
the other for sanity.)
What exactly is the problem being solved here? (Doesn't build on some
platform that's more pedanitc/less sane than Linux? Which one?)
> >15119: Nitpick: If you're going to fix the comment why didn't you fix the
> >\ after the ` to be an /? The code itself looks fine...
>
> I admit that i overread the wrong tick in Yann's patch.
I said it was a nitpick...
Rob
--
Never bet against the cheap plastic solution.
More information about the busybox
mailing list