[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: cwrapper generates long strings.
From: |
Ralf Wildenhues |
Subject: |
Re: cwrapper generates long strings. |
Date: |
Mon, 4 Oct 2010 07:00:45 +0200 |
User-agent: |
Mutt/1.5.20 (2010-08-04) |
* 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
- 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, 2010/10/03
- Re: cwrapper generates long strings.,
Ralf Wildenhues <=
- 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