Problem with coupling shared object symbol visibility with protection

Benjamin Thaut via Digitalmars-d digitalmars-d at puremagic.com
Mon Feb 16 02:13:12 PST 2015


On Monday, 16 February 2015 at 09:59:07 UTC, Walter Bright wrote:
>
> ----------
> Here is a list of all things wrong with export:
>
> 32 & 64 bit issues:
> 1) Exporting a global variable leads to a linker error
> 2) Exporting thread local variables should be an error (at 
> least it is in c++)
> 3) The module info should be exported as soon the module has 
> any exported
> symbols
> 4) __gshared members of a class are not exported
> 5) The TypeInfo Object of the TestClass is not exported
> 6) The TypeInfo Object of TestStruct is not exported
> ---------
>
> None of these are addressed by making export an attribute.

I never said that. I said that making export an attribute is 
_not_ an breaking change because it is already broken up to a 
point where it currently can't be used anyway (especially because 
of 922). My current implementation fixes both 922 and 9816 but 
would greatly benefit from making export an attribute because 
otherwise D's entire protection system would be undermined like 
described multiple times throughout this thread.


More information about the Digitalmars-d mailing list