[PATCH] D24229: [ELF] - Versionscript: do not treat non-wildcarded names as wildcards.

Rui Ueyama via llvm-commits llvm-commits at lists.llvm.org
Thu Sep 8 15:07:07 PDT 2016


On Thu, Sep 8, 2016 at 6:54 AM, Kevin P. Neal <kpn at neutralgood.org> wrote:

> On Wed, Sep 07, 2016 at 10:18:41PM +0000, Rui Ueyama via llvm-commits
> wrote:
> > ruiu added a comment.
> >
> > If you think of this, that grammar looks very weird because it lacks a
> way to write a glob pattern containing a whitespace character. For example,
> if you want to write a pattern that matches strings starting with "foo "
> followed by any characters, you need this glob pattern: "foo *". However,
> if you write that in a linker script, it means the literal string "foo *"
> instead of a glob pattern, because the token is quoted. That means there's
> no way to express that in the linker script.
> >
> > Being said that, this is what GNU does, and linker scripts are written
> that way, so unfortunately there's no way other than implementing the same
> thing.
>
> It makes perfect sense. The shell normally handles globbing. That's the
> context in which it is normally done. And the shell doesn't do globbing
> of strings that are single or double quoted. So having globbing work
> differently than it does under the shell would be a POLA violation.
>

I agree that there's some similarity between this and how shell handles
wildcards, but I think the similarity is superficial. Shell has multi-stage
command line expansion. Wildcards are expanded and then a resulting string
is tokenized. Once it is tokenized, you don't need to (and can't) tell
whether a token was quoted or not. On the other hand, in linker scripts,
wildcards are expanded in a very late stage of the process, and whether it
was quoted or not matters. That's pretty different from the shell's
semantics.

By the way, what is POLA?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160908/a32f4c27/attachment.html>


More information about the llvm-commits mailing list