[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: cwrapper generates long strings.
From: |
Peter Rosin |
Subject: |
Re: cwrapper generates long strings. |
Date: |
Sun, 03 Oct 2010 20:28:47 +0200 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 |
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
- Re: cwrapper generates long strings., Peter Rosin, 2010/10/01
- Re: cwrapper generates long strings., Ralf Wildenhues, 2010/10/02
- Re: cwrapper generates long strings., Peter Rosin, 2010/10/02
- Re: cwrapper generates long strings., Ralf Wildenhues, 2010/10/02
- Re: cwrapper generates long strings., Peter Rosin, 2010/10/02
- Re: cwrapper generates long strings., Ralf Wildenhues, 2010/10/03
- Re: cwrapper generates long strings.,
Peter Rosin <=
- Re: cwrapper generates long strings., Ralf Wildenhues, 2010/10/04
- Re: cwrapper generates long strings., Peter Rosin, 2010/10/04
- Re: cwrapper generates long strings., Ralf Wildenhues, 2010/10/04
- Re: cwrapper generates long strings., Peter Rosin, 2010/10/04