[cfe-dev] Weak pointer support on 32-bit platforms

Alp Toker alp at nuanti.com
Sun May 11 16:37:36 PDT 2014


On 12/05/2014 02:12, Hovik Melikyan wrote:
> Apologies, my bad, there is no bug. Turns out in certain circumstances
> MinGW can redefine __attribute__ to do nothing, and as a result __weak
> becomes either a simple "unsafe" ptr or for certain setups it may
> become __strong.

Hi Hovik,

If that's the case there's still a bug in clang:

The documentation describes __autoreleasing, __strong and __weak as 
attribute spellings but the implementation provides them as preprocessor 
macro definitions.

I haven't examined why this is the case but one of the two could do with 
fixing (probably the implementation given that this is causing trouble 
on a supported platform). Aaron, any idea what's happened here?

Alp.



>
> In any case, I decided to go the route of patching clang to accept a
> new type of -fobjc-runtime. For the time being the patch will be
> internal of course.
>
> --
> H.M.
>
>
> On Fri, May 9, 2014 at 11:28 PM, David Majnemer
> <david.majnemer at gmail.com> wrote:
>> Filing a bug with a reduced test-case would be helpful to get this fixed.
>>
>>
>> On Fri, May 9, 2014 at 2:25 AM, Hovik Melikyan <hovik.melikyan at gmail.com>
>> wrote:
>>> Hi David,
>>>
>>> (I should have made it clear that I do understand there's GNUstep
>>> (whose GUI is so horrible and 1990-ish that makes me want to switch to
>>> an entirely different industry altogether :) and I do understand I
>>> can't use Apple's code unless it's covered by a more or less
>>> permissive license. Libobjc is APSL so we're fine with that. As for
>>> the rest, Foundation & Cocoa, there is at least one open source
>>> implementation named Cocotron that's pretty good but is a bit behind
>>> in terms of the runtime and language features. One possibility, for
>>> example, would be to adapt Cocotron to the latest libobjc, that's all.
>>> But let's forget about higher layers for now.)
>>>
>>> My point is, theoretically there's nothing that stops clang from
>>> making Apple's libobjc compile and work on Windows, less exceptions.
>>> We can wait until clang brings exceptions to Windows, that's fine,
>>> because exceptions are kind of not critical to F/Cocoa.
>>>
>>> But weak pointers, I think what I found is a bug. You declare a __weak
>>> pointer and the compiler treats it as __strong for a particular
>>> target. The consequences of this bug for an app can be catastrophic.
>>>
>>> Let's say my setup is a bit unusual, but if there is one little thing
>>> that possibly needs a little fix, why not? I was hoping to hear some
>>> ideas as to what I can do: file a bug? suggest a patch? use some
>>> compiler flag that I didn't know of?
>>>
>>> --
>>> H.M.
>>>
>>>
>>> On Fri, May 9, 2014 at 9:29 AM, David Chisnall
>>> <David.Chisnall at cl.cam.ac.uk> wrote:
>>>> Hi,
>>>>
>>>>
>>>> On 8 May 2014, at 23:17, Hovik Melikyan <hovik.melikyan at gmail.com>
>>>> wrote:
>>>>
>>>>> And finally, the GNU compiler is not an option for me because it lags
>>>>> in some crucial aspects of the ObjC language. I really, really want to
>>>>> get clang to compile libobjc and then the entire Foundation/Cocoa
>>>>> emulation layers. Ideally, clang should be able cross-compile this
>>>>> stuff on OSX.
>>>> You seem to be conflating many parts of the stack.  For all of the stuff
>>>> that you want, you need:
>>>>
>>>> - A compiler
>>>> - An Objective-C runtime
>>>> - A Foundation / AppKit implementation
>>>>
>>>> Clang is the compiler, and supports several Objective-C runtimes.  The
>>>> only supported configurations on Windows, however, are the GNU family of
>>>> runtimes (the Apple runtime works on Windows, but requires code that Apple
>>>> has not open sourced to actually be useful).  The GCC and GNUstep runtimes
>>>> both work on Windows and the GNUstep runtime has supported ARC for several
>>>> years and is used by a number of commercial products on Windows, Android,
>>>> and so on.
>>>>
>>>> Once you have the compiler and runtime, you need a Foundation
>>>> implementation that supports the runtime.  Again, GNUstep provides this for
>>>> the GCC and GNUstep runtimes.
>>>>
>>>> I'm not sure what you mean by 'the entire Foundation/Cocoa emulation
>>>> layers'.  Foundation and Cocoa are just libraries.  You can not use Apple's
>>>> implementation on Windows[1], because Apple doesn't license their library
>>>> implementations for third parties.
>>>>
>>>> David
>>>>
>>>> [1] Unless you can find a copy of Yellow Box for Windows, in which case
>>>> you can but you'll have a *really* old version.
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-- 
http://www.nuanti.com
the browser experts




More information about the cfe-dev mailing list