Den 2010-10-03 09:01 skrev Ralf Wildenhues: >> I used 250 at the limit in the test as the 79 characters from the string >> splitter in ltmain might be doubled due to C string escapes and then I >> added some extra margin for quotes and the ", f);" trailer. Still below >> 255 which might be an arbitrary limit in some grep implementations. > > You can assume close to 2K as minimum limit for grep. > (Hmm, wonder why we didn't ever write down the value in autoconf.texi) > > The patch is OK with nits addressed. > >> --- a/tests/cwrapper.at >> +++ b/tests/cwrapper.at >> @@ -134,3 +134,53 @@ done >> >> AT_CLEANUP >> >> + >> +AT_SETUP([cwrapper string length]) >> + >> +eval "`$LIBTOOL --config | $EGREP '^(objdir)='`" >> + >> +AT_DATA([liba.c], >> +[[int liba_func1 (int arg) >> +{ >> + return arg + 1; >> +} >> +]]) >> +AT_DATA([usea.c], >> +[[extern int liba_func1 (int arg); >> +int main (void) >> +{ >> + int a = 2; >> + int b = liba_func1 (a); >> + if (b == 3) return 0; >> + return 1; >> +} >> +]]) >> + >> +AT_CHECK([$LIBTOOL --mode=compile $CC $CPPFLAGS $CFLAGS -c liba.c], >> + [], [ignore], [ignore]) >> +AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -no-undefined ]dnl >> + [-o liba.la -rpath /foo liba.lo], >> + [], [ignore], [ignore]) >> +AT_CHECK([$CC $CPPFLAGS $CFLAGS -c usea.c], >> + [], [ignore], [ignore]) >> + >> +# make sure PATH is at least 250 chars, should force line breaks in >> lt-usea.c >> +for i in 25 50 75 100 125 150 175 200 225 250 >> +do >> + PATH="$PATH$PATH_SEPARATOR/somewhere-that-eksists-not" > > Intended typo 'exists'? ;-)
Yes :-) > Does $LIBTOOL or the autotest machinery ever intentionally try to run > commands that won't exist in $PATH within this shell? I don't think so, and it is a really hard question to answer too. > If so, then we > might get the odd bug report from security-hardened distributions that > complain about read or execute accessses to non-allowed parts of the > file system. Using "$PATH$PATH_SEPARATOR$PATH" seemed like a much quicker way to make the length explode so I didn't like that. > This length doesn't yet trigger the compiler string literal length > limit; not sure whether it should? That's not reliable anyway as most compilers support so long strings that it's hard to tickle it. On a tangent, another bug is that linking doesn't fail (libtool returns zero) when building the cwrapper fails. I think that's a separate issue from this one, which is why I haven't mixed them up previously. Another nit in that area is that there are multiple levels of "$opt_dry_run || {" which seems superfluous, but that might be intentional in order to keep the code copy-paste-safe? > Do we have to cater to the case where the environment is very large > already? I'm not sure, we might want to deal with it when crossing > that bridge only, if it's hard to know off-hand. Are your three above paragraphs nits and part of what I need to address, or just notes for the future? >> +done >> +export PATH >> + >> +AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -no-fast-install ]dnl >> + [-o usea$EXEEXT usea.$OBJEXT liba.la], >> + [], [ignore], [ignore]) >> + >> +# skip if no cwrapper is generated >> +AT_CHECK([test -f $objdir/lt-usea.c || exit 77]) >> + >> +# try to make sure the test is relevant >> +AT_CHECK([grep ' *fputs' $objdir/lt-usea.c > /dev/null]) > > Rather than redirecting stdout, put [ignore] in the third argument. Certainly possible, but I didn't think anyone would be interested in a couple of hundred lines of boilerplate in the log. I don't really care though, so if you still think [ignore] is a good idea, then ok. >> +# check for no overly long fputs >> +AT_CHECK([grep ' *fputs.\{250\}' $objdir/lt-usea.c], [1]) >> + >> +AT_CLEANUP Cheers, Peter