I broke patch's ability to create files in November, and nobody noticed in
the ensuing 11 months. Sigh.
Signed-off-by: Rob Landley <rob@landley.net>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
1) Eliminate spurious warnings about possibly reduced hunks. Instead only
note a possible location if we don't find a non-reversed place to apply it.
(Otherwise, hunks that move code forward around within a file look reversed at
the removal site.)
2) Open the source file read-only, so we can apply patches to read-only files.
Signed-off-by: Rob Landley <rob@landley.net>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Makes it slightly smaller and (in my opinion) clearer.
Signed-off-by: Rob Landley <rob@landley.net>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
parsing an escape sequence. (This mitigates but doesn't fully fix the
the "cursoring around the file deletes data under qemu" bug, presumably due
to "\033[D" being treated as three separate characters.)
generated binaries, to make copyright enforcement easier. Our liason with
them (Bradley Kuhn) suggested the following text:
> Copyright (C) YEAR-2006 Erik Andersen, Rob Landley, and others.
> Licensed under GPLv2. See source distribution for full notice.
And the busybox help message seems the least offensive place to put it. (At
some point in the future, I need to strip 128 bytes from the binary to feel
good about this, though. :)
Minor header file cleanup while I was there, since libbb.h already #includes
most of that stuff...
tree, we have the warning about failed inlines (which with our inline
limit set to zero means any usage of the "inline" keyword at all). Note
that setting the inline limit to zero, and using -Werror, both predated
adding the warning about inlines to the tree. So whatever checkin added
that did nothing but break the tree. But oh well.
The second category of superfluous warnings is warning about functions with
no previous declaration. Apparently, if you add ALWAYS_INLINE to an empty
function definition, it considers the sucker undeclared as far as the
warning is concerned. (I.E. it's a buggy warning. I try not to ask the
compiler to generate warnings it can't competently generate.)
This is why I removed "inline" (unbreak allbareconfig), and couldn't replace it
with "ALWAYS_INLINE" (still broke allbareconfig).
We've had -Werror in the tree for quite a while, so adding #warning
somewhat counterproductve way to make comments on the code that belong on the
mailing list anyway.
License" with "BusyBox is licensed under the GNU General Public
License version 2 or later... (This is the same license the Linux kernel
is under...)" Except that the Linux kernel isn't under GPLv2 or later,
it's just under GPLv2.
Now they match again.
I don't know why patch decided to apply this even though it was already in
the tree. I thought the other hunks failed because they were totally
unrelated leakage from Bernhard's tree (which they are; was the a reason
for bundling them in with this fix? Do they have something to do with
the GCC 2.95 fix? I suspect they prevent me from backporting this
patch to 1.2.2 because the header consolidation into libbb.h hadn't
been done yet, and no I'm not fixing it up: if that's the case then
this patch won't be in 1.2.2 due to extraneous changes bundled with it that
prevent a clean backport without rolling a new patch).
One of the pads turned out to be unnecessary: sizeof(struct TarHeader) is
TAR_BLOCK_SIZE, the padding's in the struct. The others could be done inline
with bb_common_bufsiz1.
This is a cleanup I did to Denis' patch long ago, but got sidetracked by
what turned into svn 15660.
The minimal version got a couple hundred bytes bigger, partly because it's
broken into more functions but mostly because it now dynamically reallocates
and frees everything with no hard-coded limits. (I thought about making
that optional, but there's a limit to what I can debug and maintain. It
should still be reasonably NOMMU friendly, the allocations are small and
short lived, and shouldn't contribute noticeably to long-term memory
fragmentation.)
applet list yet (and won't be until it can replace lash, I'm not having five
shells in menuconfig at once), but you can build it with scripts/individual
and mostly this is checked in so I can bloatcheck future versions against it
easily....
This is about as small as a shell can get and still be a shell.
--gc-sections linker flag with static linking. If this happens, then
the "stdout" variable (used by printf() and such) will only work if stdout
is _not_ redirected. I.E "./busybox" prints stuff, but "./busybox | cat"
does not produce any output. (But even when redirected, "write(1,"blah",4);"
continues to work just fine.)
This is clearly a glibc bug, but to avoid triggering it I've moved the
--gc-sections flag so it only gets added when we're not statically linking.
If somebody would like to go poke Ulrich Drepper, you can trivially reproduce
this with a "hello world" program, ala:
gcc -static -Wl,--gc-sections hello.c && (./a.out | cat)
the terminal the way mingetty does instead of the way agetty does. It's
a bit ugly for somebody else to be writing to a console sitting at a
login: prompt, but it's uglier when newline doesn't work as expected if
they do.
The following patch makes coreutils/test.c act fail gracefully if getgroups()
returns a -1. This fixes a problem on the One Laptop Per Child ROM image
whereby we were getting odd Memory exhausted messages for '[' and 'test'.
Found by Mitch Bradley <wmb@firmworks.com>
(Tweaked by Rob: no need to initialize a static to NULL, or realloc something
that's only allocated when it's NULL.)
except that we still have to work when there is no mtab.
Oh, and while we're at it, take advantage of the fact that modern processors
avoid branches via conditional assignment where possible. ("x = a ? b : c;"
turns into "x = c; if (a) x = b;" because that way there's no branch to
potentially mispredict and thus never a bubble in the pipeline. The if(a)
turns into an assembly test followed by a conditional assignment (rather
than a conditional jump).) So since the compiler is going to do that _anyway_,
we might as well take advantage of it to produce a slightly smaller binary.
So there.
few new (unfinished) config options, which I intend to make hidden (but
enabled) when CONFIG_NITPICK is disabled. Getting the .config infrastructure
to do that is non-obvious, it seems...
teach scripts/individual new tricks. And while I'm at it, teach
scripts/individual other new tricks. Now builds 198 applets, some of which
I should teach it to hardlink together because they're really the same app...
http://busybox.net/lists/busybox/2005-September/015766.html
I renamed it "individual" to not confuse it with the standalone shell. (Which
it isn't compatible with for obvious reasons.) Configure busybox (I did
make defconfig), then run scripts/individual and it'll build an individual
version of each applet in the "build" subdirectory.
Currently it builds 146 and fails to build 104 applets out of "make defconfig".
I haven't taught it about multi-file applets yet (like tar), or the ones where
two applets get built from the same source (for example, zcat is a trivial
variant of gunzip so there is no zcat.c). But here's a start.
O_CREAT. Two users are still doing it (and thus getting permissions 777),
I'm not sure what permissions they should be using but here they are
changed to xopen3(). This costs us a dozen or so bytes, but removing the
777 from xopen() should get some of that back.
were using "1" as one of the arguments anyway, and as for the rest a multiply
and a push isn't noticeably bigger than pushing two arguments on the stack.
a failed mount. And while I'm at it, legacy mdev removal was only being done
in the _failure_ case? That can't be right. Plus minor header cleanups
and an option parsing tweak.
Rob Landley