[BusyBox] busybox, sed, and zlib's configure script

[Rob Landley]

On Monday 22 September 2003 06:57, Glenn McGrath wrote:
> On Mon, 22 Sep 2003 04:16:31 -0400
>
> Rob Landley <rob at landley.net> wrote:
> > I'm not sure if the problem is busybox producing an invalid config or
> > some bug in uclibc coming out of the woodwork.  I'm going to do a
> > static build of ld with the straight gnu toolchain (glibc, gnu sed,
> > etc.) and compare the config to see if that reveals anything obvious,
> > then re-introduce uclibc and busybox separately to try to narrow this
> > down.
>
> When i was testing to see if busybox could build a correct Makefile, i
> just made one in each environment and did a diff.
>
> > Oh, one more thing: in order to get binutils to configure properly,
> > sed needs the newline matching hack enabled.  What exactly IS the
> > warning regarding that?  (Some kind of standards violation?  The meat
> > of the hack seems to replace \n with \\n, but there's some other
> > ifdefs I didnt'have time to trace throught due to playing with
> > experimental kernels.)
>
> The hack modifies the pattern prior to it being processed by the regcomp
> command.
> It also modifies the text before and after the regex is applied to it.
>
> I put some more #ifdef's in recently, it defines different behaviour
> between GNU sed and posix sed.
>
> I put the newline warning in because i expected it to break something,
> but i couldnt think of any other way around the problem without
> rewriting regex handling. (the problem being libc's dont support pattern
> matching with a newline character as part of the pattern.

I was thinking of going with an escape sequence more like \0xFF\0x01, and then 
when adjusting the buffer replacing any actual 0xff with \0xff\0x02.  (Ugly 
and inefficient, but it wouldn't clash with any incoming datastream and 0xff 
is extremely unlikely to occur in the datastream anyway.)  But I wanted to 
read through the rest of the code first to make sure I understood the 
problem, and just didn't have time this weekend...

Fixing the libc regex handling would be a _much_ better solution, though.

> Now looking at the standard for regex (1) it says
> "If REG_NEWLINE is not set in cflags, then a <newline> in pattern or
> string shall be treated as an ordinary character."
> Ive tried with and without REG_NEWLINE being set in glibc and it doesnt
> work in either case, maybe its a bug in glibc, i havent tested it in
> uclibc.
>
> 1) http://www.opengroup.org/onlinepubs/007904975/functions/regcomp.html

I'll try to thump on it later this week, but the monday/tuesday insane 
schedule is creeping back up on me...

> > What's a test case that would fail because of this hack being enabled?
>
> This works
>
> $ echo "\n" | sed 's/\\n/foo/'
> foo
> $ echo "\n" | ./busybox sed 's/\\n/foo/'
> \foo
>
>
> These dont
> $ echo "\n" | sed 's/\n/foo/'
> \n
> $ echo "\n" | ./busybox sed 's/\n/foo/'
> \foo
>
>
> $ echo "\n" | sed 's/\\\n/foo/'
> \n
> $ echo "\n" | ./busybox sed 's/\\\n/foo/'
> foo

Seems like the behavior of all three differs between gnu and busybox sed...?

Rob