Re: rewrite try_dlopen (1)

[Gary V. Vaughan]

Hey Ralf!

Ralf Wildenhues wrote:
> * Gary V. Vaughan wrote on Mon, Oct 04, 2004 at 01:34:05PM CEST:
> 
>>Ralf Wildenhues wrote:
>>
>>> But for the syntax, I'm thinking along these lines:
>>>
>>>- it must be Bourne-shell source-able.
>>>- A line is either
>>>    empty
>>>    a comment (starts with #)
>>>    or a (complete!) variable assignment.
>>>- The right-hand side of a variable assignment should either be
>>>    single-quoted
>>>    or not quoted at all (and consist of one word only).
>>
>>There are some double quoted fields in the .la files I just glanced at
>>(relink_command in this case), though there is no reason that particular case
>>couldn't use single quotes.  I think it is a good idea to specify that to
>>reduce surprises from shell expansion.
> 
> 
> I was not so sure about that (the fact that single quotes suffice).
> But alas, since there is usage now, we have to support it anyway.

We can have the parser warn about it from the testsuite, and stop generating
double quoted values in future .la output.  It has got to be a stability win
when the variable always contains what it says in the .la file
character-for-character.

>>>- The libltdl parsing *must* yield the same value as shell sourcing
>>>  in case that
>>>    no variable expansions are used ($foo)
>>>    no shell wildcards are used (libfoo*)
>>>    no config.status expansions are used (@foo@)
>
> For now I want to keep these expansions out of the ltdl
> code.  Fine with me to use them for `libtool'.  But then we must specify
> which variables are (un)interesting for ltdl.
> 
> Usage within `libtool' can (and in fact does right now) undergo
> globbing, variable expansion and such.  Basically all three of the above
> I mentioned.

Indeed.  A whole different kettle of fish.

Our goal here is for a fully specified .la format that will allow third party
generated .la files.

> There is no real security implication here, anyone getting in
> our library path has already won.

Good point.

> What I'd like to prevent is segfaults
> (assertions are segfaults, too; production code ignores assert()) that
> stem from buggy files.  They should preferably return a meaningful
> error.  In fact a patch adding an error is pending, one reason for my
> question about binary incompatibility (which I'd still like to have
> answered more conclusively).

Amen to that!

And `Halleluja' for readable error messages from the parser :-)

>>>Any objections against these?  I think they are backwards-compatible in
>>>the sense that newer libltdl should be able to read older .la files this
>>>way.

Okay:  With your clarification wrt shell expansions, and given support for
double quoted values (deprecated or otherwise), I can't imagine a scenario
where a legacy .la will fail to be read by a parser implementing the rules
we've discussed in this thread.

Cheers,
        Gary.
-- 
Gary V. Vaughan      ())_.  address@hidden,gnu.org}
Research Scientist   ( '/   http://tkd.kicks-ass.net
GNU Hacker           / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook

signature.asc
Description: OpenPGP digital signature