[swift-dev] swift (ABI) and Windows

[Saleem Abdulrasool]

On Wed, Apr 6, 2016 at 11:34 AM, Jordan Rose <jordan_rose at apple.com> wrote:

>
> On Apr 6, 2016, at 11:31, Saleem Abdulrasool <compnerd at compnerd.org>
> wrote:
>
> On Wed, Apr 6, 2016 at 11:18 AM, Jordan Rose <jordan_rose at apple.com>
> wrote:
>
>> Hey, Saleem. How do you expect this to differ from normal symbol
>> visibility? It seems to me that in a shared library, any public symbol is
>> either exported or imported, depending on whether it has a definition, and
>> any non-public symbol is default. (Unlike C, we expect to have sensible
>> rules here.) I guess there's the difference between "a public symbol from
>> elsewhere in this library" and "a public symbol from some other library".
>> Is that it?
>>
>
> Well, there are four cases to consider:
> - externally available: imported
> - defined (and available for others): exported
> - defined (statically): default -- won't even show up, so this is a no-op
> - defined (non-statically defined for internal use): default
>
> The thing is that there is no modeling for internal symbols which other
> shared objects can use.  The closest thing you can do is anonymize the
> symbol (so you don't have a name that you can call it by, but you have an
> integral ID).
>
>
> What is an "internal symbol which other shared objects can use"? That
> sounds like a self-contradiction.
>

This is used for things like providing private hooks across shared
objects.  These would usually be anonymized (nameless), but you get an
integral ID that gives you an index into a table of pointers to the
function or variable that you are interested in.


> Jordan
>



-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160406/46633fe9/attachment.html>