[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