Eric Blake <[EMAIL PROTECTED]> wrote: > According to Gary V. Vaughan on 10/1/2008 10:09 PM: >>> I'm working on making m4 1.6 transparently handle NUL, >> >> Excellent! I made an attempt to do that myself on the 2.0 branch some >> years ago, but it didn't go well so I never committed... > > The argv_ref branch already does this; it is just a matter of finishing > porting it to branch-1.6 and master (and in the process of that porting, I > discovered that the tests I wrote worked fine under GNU sed but died under > Solaris 10). > >>> or can have false positives (if both >>> stderr and expected error are normalized, then regressions involving >>> added >>> or missing NUL are not detected). I don't want to require perl for just >>> this one test; m4 seems fundamental enough to keep the testsuite >>> restricted to the GNU coding standards set of tools. >> >> I'd be inclined to do that in C. A few lines should be sufficient to >> write a minimal filter that writes '\' '0' or '^' '@' to output whenever >> a NUL byte arrives? > > Actually, I'm a bit lazy - I guess I'm okay with false positives on > Solaris when using deficient sed, so long as we can also run on Solaris > with GNU sed. So I'm installing this patch, which lets the user select > the right sed, as well as passing both files through sed (a no-op for GNU > sed, but strips NUL bytes equally for Solaris sed). (At any rate, it was > easier to code than searching for a tr that handles NUL). > > Should I also modify configure.ac to call AC_PROG_SED, and feed that as > the default for $SED in the check script? (The master branch is currently > the only branch that uses $SED, thanks to libtool.)
Hi Eric, You could also just skip the affected tests when configure fails to find an appropriate sed command. In general, I prefer to skip tests than to get false positives, since that decreases the likelihood of problem reports ;-)