My initial thoughts are:
1. add an escape character of some kind to insert a literal ':'
2. please make all pathnames use a consistent syntax
3. don't implement any special work arounds unless you know there are
users of the feature
4. dlopen("foo:bar", RTLD_LAZY | RTLD_FULLPATH)
This is really gross! I always thought I was just passing
a library, not a list! Is this true for all rtld
functions that take a library name?
So I see two different kinds of strings we are dealing with:
1. a colon-separated list of directories (can be a list of one)
2. a colon-separated list of libraries (can be a list of one)
Is that true?
$ISALIST could be implemented by using direct iteration right?
It doesn't actually have to expand to a colon-separated
list of libraries, does it? Does anyone use that feature otherwise?
Can we pretend it was a bug, and remove that feature? ;-)
--chris
Rod Evans wrote:
> Presently, no. But it seems like a mechanism to allow ':' within
> a path is now desirable.
>
> I've a couple of thoughts. First, if you wish to allow ':' within
> a dlopen() path, would you also want to allow this character in
> a RUNPATH, LD_LIBRARY_PATH, or some other ld.so.1 processed path?
> We could invent an escape character that can be embedded in a path.
> This provides generic flexibility, but in the case of dlopen()
> might require the user to translate a string (read from some config
> file?) to include the escape character.
>
> Or, we could allow dlopen() path processing to differ/be-more-flexible
> than other path processing. We could force a dlopen() string to be
> used as-is. This changes todays behavior, and would break the example
> I had cited below. But, would anyone care? Or we could be explicit
> in regards our new requirement:
>
> dlopen("foo:bar", RTLD_LAZY | RTLD_FULLPATH)
>
> and use a new token to define a path should be used as is.
>
> Thoughts?
