[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-readline] [PATCH] Enable visibility annotations

From: Pedro Alves
Subject: Re: [Bug-readline] [PATCH] Enable visibility annotations
Date: Fri, 22 Apr 2016 18:38:28 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1

On 04/22/2016 06:02 PM, Yury Gribov wrote:
> On 04/22/2016 06:15 PM, Pedro Alves wrote:

>> That's my point -- the inconsistency _is not_ inevitable -- if we're
>> making them private, them programs won't be able to use them anyway, so
>> might as well remove them altogether.  Or at least rename them
>> to "_rl_" prefix.
> If they are not called inside readline - sure. 

If they only exist so that they can be inside readline nowadays,
then they should be renamed to avoid the "rl_" prefix.

> Just wanted to point out
> that this is not a general solution for inconsistency in static vs.
> dynamic library behavior w.r.t. visibility.

I'm only talking about "rl_" symbols that _only_ exist to keep
backward compatibility.  Making them private makes them pointless, as
backward compatibility becomes broken.  Unless you link against the static
readline.  This is the inconsistency I'm talking about.  If it's possible
to make a "for backward compatibility" symbol private, it's because the
backward compatibility is no longer necessary, so it should be also possible
to remove or rename the symbol, thus effectively making linking with
a static readline behave the same.  If it's decided that the symbols
should _still_ remain as is for continued backward compatibility, then
they should be made public on the dynamic link as well, irrespective of
whether we found a program that uses them, again eliminating the
dynamic vs static inconsistency.

Pedro Alves

reply via email to

[Prev in Thread] Current Thread [Next in Thread]