Re: cwrapper generates long strings.

[Peter Rosin]

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