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

Mon May 12 11:20:08 PDT 2014

On Sun, May 11, 2014 at 4:59 PM, Hovik Melikyan <hovik.melikyan at gmail.com>wrote:

> 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.
>

You can probably work around this with -D__GNUC__=4.

However, why do you need -fms-compatibility if you are using MinGW?

> 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
> >
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140512/bf884736/attachment.html>