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

[Hovik Melikyan]

Hi Alp,

On Mon, May 12, 2014 at 12:37 AM, Alp Toker <alp at nuanti.com> wrote:
>
> The documentation describes __autoreleasing, __strong and __weak as
> attribute spellings but the implementation provides them as preprocessor
> macro definitions.
>

Actually no, the documentation says: "The names of the ownership
qualifiers are reserved for the implementation. A program may not
assume that they are or are not implemented with macros, or what those
macros expand to."

http://clang.llvm.org/docs/AutomaticReferenceCounting.html#spelling

This may lead to unpleasant surprises though, like with MinGW. More
specifically, when clang is in -fms-compatibility mode it doesn't
define __GNUC__ and that in turn makes MinGW think __attribute__ and
some other things should be masked.

So the source of confusion here might be that __attribute__ is a "GNU
thing" (correct?), at the same time __weak is not, but relies on it.

--
H.M.


On Mon, May 12, 2014 at 12:37 AM, Alp Toker <alp at nuanti.com> wrote:
>
> 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
>