Re: cwrapper generates long strings.

[Ralf Wildenhues]

* Peter Rosin wrote on Sun, Oct 03, 2010 at 08:28:47PM CEST:
> Den 2010-10-03 09:01 skrev Ralf Wildenhues:
> >> +for i in 25 50 75 100 125 150 175 200 225 250
> >> +do
> >> +  PATH="$PATH$PATH_SEPARATOR/somewhere-that-eksists-not"

> > 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.

Indeed.

I'm kinda wondering whether we should at least delimit our use of
nonexistent files and directories to a common subtree, like below
/nonexistent or so.  I realize we're getting near bike shedding
issues though, so how about we cross that bridge when we get to it,
and leave your patch as is for now.

> >  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.

OK.

> > 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.

FWIW, that is not necessary.  It would be sufficient if it were tickled
with the one compiler in question.

> 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.

OK, good.

> 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?

Not sure.  I don't have much sympathy for copy-paste-safety, because
I dislike the kludge that copy-paste is.  Functions should be used
instead.  So yes, I guess a cleanup is a good idea, after ensuring that
the code really works fine with the outer opt_dry_run enclosing.

> > 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?

They started out as nits, but I guess they've become notes by now.
So go ahead with your patch, please.

> >> +# 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.

Ah yes.  Autoconf 2.64 provides stdout-nolog for this, but I guess you
can keep the code the way it is, for compatibility.

Thanks,
Ralf