For certain non-gcc compilers, alloca_h is defined (included) but there,
no alloca() is declared. Fallback to malloc if _ALLOCA_H is defined but
still, there is no alloca() in the included _ALLOCA_H.
Hi,
I found that gcc in cvs (HEAD in 2005/02/11) reject the gzip source
in the busybox.
This is caused by changing gcc's error handling behavior(
The gcc check the function prototype more strictly).
I show the compilation log as follow:
-- compilation log
-- compilation log
To fix the problem, apply the patch which is attached with this
mail.
Please take a look the patch and apply the patch into svn repository.
Is the change on libbb/loop.c which you commited in 2005/1/3 effective
really?
The __GLIBC__ macro and __UCLIBC__ macro are defined in
feature.h in glibc source, so the change may not be effective.
If you want to check this with __GLIBC__, feature.h header is needed.
Some architectures(e.g. PPC series) need to include linux/posix_types.h
in stead of asm/posix_types.h, so the patch which is attached with
this mail include <linux/posix_types.h>.
and with multiple files SuSv3 says it should only trigger at the end of the
LAST file.
The trivial fix I tried first broke if the last file is empty. Fixing this
properly required restructuring things to create a file list (actually a
FILE * list), and then processing it all in one go. (There's probably a
smaller way to do this, merging with append_list perhaps. But let's get
the behavior correct first.)
Note that editing files in place (-i) needs the _old_ behavior, with $
triggering at the end of each file.
Here's a test of all the things this patch fixed. gnu and busybox seds produce
the same results with this patch, and different without it.
echo -n -e "1one\n1two\n1three" > ../test1
echo -n > ../test2
echo -e "3one\n3two\n3three" > ../test3
sed -n "$ p" ../test1 ../test2 ../test3
sed -n "$ p" ../test1 ../test2
sed -i -n "$ p" ../test1 ../test2 ../test3
to not put a newline at the end (which was backwards, it should have been
hardwired _to_ put a newline at the end, whether or not the input line
ended with a newline). Test case for that:
echo | sed -e '$ctest'
And then this would segfault:
echo | sed -e 'g'
Because pattern_space got freed but the dead pointer was only overwritten
in an if statement that didn't trigger if the hold space was empty. Oops.
While debugging it, I found out that the hold space is persistent between
multiple input files, so I promoted it to a global and added it to the
memory cleanup. The relevant test case (to compare with That Other Sed) is:
echo -n woo > woo
sed -e h -e g woo
echo "fish" | sed -e '/woo/h' -e "izap" -e 's/woo/thingy/' -e '/fish/g' woo -
And somebody gratuitously stuck in a c99 int8_t type for something that's just
a flag, so I grouped the darn ints.
