[PATCH] misc size-shrinkage; merges

Bernhard Fischer rep.nop at aon.at
Tue Aug 29 19:22:06 UTC 2006


On Tue, Aug 29, 2006 at 03:06:22PM -0400, Rob Landley wrote:
 
>> 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 saved that .config also to
http://busybox.net/~aldot/bb/busybox.config.Breeze

Not sure why you think pointing out a bug insults you.

>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 

I changed the type of n to avoid compiler warnings, also (IIRC, would
have to look) i and n were used for two things, which created bigger
code for gcc-4.0.

>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 

As you can see, trunc_flag is used right there, so it's nice to see
nearby what it is.

>(Because the #define will respect the scope of the function, sure!  The 

You aren't being sarcastic, are you?

>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 just copy and pasted them from the original names. You wouldn't assign
anything to them, or wouldn't be able to anyway.
>
>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.

Again, someone on IRC pointed out a bug, didn't want to subscribe to the
list, and stated the fact that trunk doesn fail his example. That
example did work before. No idea why you think that's a personal insult.



More information about the busybox mailing list