<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">I thought I sent out this email earlier. But here it is again.<div><br></div><div>__weak is always defined for use in blocks. It is unfortunate though that it is def’ed to<div>objc_gc(weak) though. But for the purpose of use, it doesn’t really matter.</div><div><br></div><div>- Fariborz</div><div><br></div><div><br></div><div><div>On Jun 5, 2013, at 10:57 AM, Frank Rehwinkel <<a href="mailto:frankrehwinkel@gmail.com">frankrehwinkel@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div dir="ltr">Totally agree. But I'm just coming to the GNUstep project. And while it used to be supported for Darwin - before clang was an option, it seems an unsupported platform option these days - ironic really. So I'm a little bit on my own on this one and just trying to make it compile with the minimum of changes to see if it will even work again.<div><br></div><div>Just had another look at the code. Maybe __strong and __weak can be undef'ed when the platform is Darwin/clang. </div><div><br></div><div>For that matter, now I' curious what is different about this build on FreeBSD, where GNUstep is actively maintained and clang is used. I know they wouldn't have left these warnings as part of their build.</div><div><br></div><div>Thanks.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 5, 2013 at 1:09 PM, John McCall<span class="Apple-converted-space"> </span><span dir="ltr"><<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;"><div><div class="h5"><div>On Jun 5, 2013, at 10:06 AM, John McCall <<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>> wrote:</div><blockquote type="cite"><div style="word-wrap: break-word;"><div><div>On Jun 5, 2013, at 10:04 AM, Frank Rehwinkel <<a href="mailto:frankrehwinkel@gmail.com" target="_blank">frankrehwinkel@gmail.com</a>> wrote:</div><blockquote type="cite"><div dir="ltr">Thanks for asking. I just want to make sure I understand your statement and question. On Darwin, you've always had __weak defined as <span style="font-family: arial, sans-serif; font-size: 12.800000190734863px;">__attribute__((objc_gc(weak))), even when __strong is defined as <empty>?</span><div><span style="font-family: arial, sans-serif; font-size: 12.800000190734863px;"><br></span></div><div><span style="font-family: arial, sans-serif; font-size: 12.800000190734863px;">If it is intentional, then I would say there is no specific problem. We can put a comment into the header file for GNUstep to explain why __weak is being undef'ed before it is defined as <empty>. (Without the undef, the build generates seemingly hundreds of warnings, obscuring other warnings that might be more meaningful.)</span></div><div><span style="font-family: arial, sans-serif; font-size: 12.800000190734863px;"><br></span></div><div><span style="font-family: arial, sans-serif; font-size: 12.800000190734863px;">If it is unintentional, then a change to clang would obviate the additional code in the GNUstep header and save a few seconds every time someone went to read through the logic of those __strong and __weak macro definitions.</span></div></div></blockquote><br></div><div>Why don't you just not #define __weak and __strong on Darwin?</div></div></blockquote><br></div></div><div>Or, for that matter, if they're already defined?</div><div><br></div><div>Headers that randomly change macro state are somewhat evil; among other things, they tend to introduce nasty order-of-inclusion bugs.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>John.</div><br></font></span></div></blockquote></div><br></div>_______________________________________________<br>cfe-dev mailing list<br><a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</div></blockquote></div><br></div></body></html>