[PATCH] misc size-shrinkage; merges

Rob Landley rob at landley.net
Tue Aug 29 19:06:22 UTC 2006


On Monday 28 August 2006 7:57 pm, Bernhard Fischer wrote:
> On Sun, Aug 20, 2006 at 04:48:06PM -0400, Rob Landley wrote:
> >On Sunday 20 August 2006 8:31 am, Bernhard Fischer wrote:
> >> On Fri, Aug 18, 2006 at 11:49:01PM -0400, Rob Landley wrote:
> >> >On Friday 18 August 2006 11:53 am, Bernhard Fischer wrote:
> >> >> Hello,
> >> >> 
> >> >> Just a heads up..
> >> >> I plan to push the below patchset (split-up, of course) into my
> >> >
> >> >Yes please.  (Reviewing 4000 lines at once ain't fun.)
> >> >
> >> >> 'busybox_scratch' branch soonish, then merge that branch back into
> >> >> trunk.
> 
> I merged most of the lingering changes off the busybox_scratch branch
> back into trunk in r16009.
> 
> A few notes.
> 
> I mean to merge (parts of) trunk back into my branch.
> There are, however, severe defects on current trunk;
> 
> 1) trunk is b0rk
> This config (off IRC, tell me if it went offline when you happen to read
> this) fails basic tests. http://rafb.net/paste/results/XtWePX12.html
> Failing use-case: echo `echo a=b | cut -d'=' -f2`

Oh wow, the development branch of a project that's four months away from the 
next release has a bug.  This is unprecedented!

The URL you gave is 404.

I'll happily fix this for you if I can reproduce it, but at the moment I have 
to figure out why svn 16007 broke the build.  (archival/tar.c now breaks 
while building on 4.0.3, but the description of the checkin says that it just 
bumped the revision number.  The commit wouldn't happen to be doing 8 
gazillion random things that aren't mentioned in the description, would it?)

> 2) trunk is bl0ated
> that ctype change from Rob is nothing i will pick up.

I never asked you to.

> It may improve 
> size overall, but it is suboptimal at any rate and should never have
> been committed (is${foobar}() from ctypes.h undefines, to be specific).

The only judgement I can use about what to apply and what not to apply is my 
own.

I inherited a situation where the svn is a shared repository where people can 
throw all sorts of white noise into it, like svn 16009 which is a bundle of 
unrelated changes, many of them bad.

For example, that the changes that commit makes to xfuncs mostly consist of 
turning c99 // comments into single line /* */ comments, for no readily 
apparently reason.

The changes that commit makes to dd include a large swath of indentation 
changes, and renaming "i" as the index variable for a loop to "n" (oh yeah, 
that's MUCH easier to grep for) and gratuitous whitespace changes like 
turning single line if statments into two line if statements.  Plus this 
little gem:

 int dd_main(int argc, char **argv)
 {
+#define sync_flag      (1<<0)
+#define noerror                (1<<1)
+#define trunc_flag     (1<<2)
+#define twobufs_flag (1<<3)
+       int flags = trunc_flag;

Yup, #define constants mixed in with variable declarations in a function 
(Because the #define will respect the scope of the function, sure!  The 
preprocessor knows all about that.)  And they're lower case to look like 
normal variables, because putting them in ALL_CAPS would give away the secret 
that they're preprocessor macros, and we wouldn't want to do that...

I mostly hold my tongue about this sort of thing, but not when the person who 
commits this stuff starts insulting the job I'm doing.

Rob
-- 
Never bet against the cheap plastic solution.



More information about the busybox mailing list