[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