Bus error gcc compiler for any for ( x in array ) inside Objective-C++ template

[John Holdsworth <mac@johnholdsworth.com>]

Hi,

I've encountered a bus error using Apple's gcc in Xcode 3.1, 3.2
compiling  the following code or any containing for( x in y ) is used
inside a template in Objective-C++.

template <typename ETYPE>
class OODictionary {
	void boom() {
		NSArray *keys = nil;
		for ( NSString *key in keys ) {
		}
	}
};

I've not been able to build with a more recent gcc so I can't tell
if it is still present but figure I'd better let you guys know.

Thanks,

John H.
http://objcpp.johnholdsworth.com


On 8 Sep 2009, at 21:30, John Holdsworth wrote:

> Hi,
>
> I've found it very useful to be able to use C++ to extend Objective-C
> using a little judicious operator overloading and I notice that  
> gcc-4.2
> now automatically "unboxes" wrapper classes with no warning when
> they are messaged - provided an appropriate cast is available.
>
> For example:
>
> class AStringClass {
> 	NSMutaableString *str;
> public:
>  	AStringClass( NSMutableString *str ) {
> 		this->str = str;
> 	}
> 	operator NSMutableString * () {
> 		return str;
> 	}
> };
>
> This class can now be messaged in gcc4.2 as below without a warning:
>
> 	AStringClass aString( nil );
> 	[aString doubleValue];
>
> Unfortunately is can also be sent a message which the compiler
> is in a position to know is not available given the only cast
> available was to a NSMutableString:
>
> 	[aString count]; // not a valid method for NSMutableString *
>
> This happens as internally as there is an implicit cast to type "id"  
> in
> ${GCCROOT}gcc/objc/objc-act,c, function: objc_finish_message_expr
>
> 	  /* APPLE LOCAL begin decay function/array receivers */
> #ifndef OBJCPLUS
> 	  /* In C need to decay array/function receivers so can be converted
> 	     to id. */
> 	  struct c_expr exp;
> 	  exp.value = receiver;
> 	  exp = default_function_array_conversion (exp);
> 	  receiver = exp.value;
> 	/* APPLE LOCAL begin radar 3533972 */
> #else
> 	  if (can_convert_arg (objc_object_type, TREE_TYPE (receiver),
> 				receiver, LOOKUP_NORMAL))
> 	    {
> 	      /* In rare cases, 'receiver' must be converted to type 'id'  
> using
> 	         user-defined type conversion. 'id' is type of the 1st  
> argument to
> 	         objc_msgSend (id self, SEL op, ...); */
> 	      tree cnv_rec = perform_implicit_conversion (objc_object_type,  
> receiver);
>              if (cnv_rec && cnv_rec != error_mark_node)
> 	        return objc_finish_message_expr (cnv_rec, sel_name,  
> method_params);
> 	    }
> 	/* APPLE LOCAL end radar 3533972 */
> #endif
>
> Would it not be possible for the implicit conversion retain the type
> which it was forced into using when searching for a match for "id"
> and using this as the type of the receiver of the message rather
> than "id". I've looked and the code but can't quite get to where
> the change (probably quite a small one) would need to be made.
> Perhaps even, this is already fixed...
>
> Can anybody help?
>
> John Holdsworth
> objcpp.johnholdsworth.com
>
>
> On 8 Apr 2009, at 14:34, David Ayers wrote:
>
>> Am Samstag, den 21.03.2009, 11:59 +0100 schrieb John Holdsworth:
>>
>>> I was wondering if it would be a useful extension to Objective-C
>>> expand the [] operator
>>> to support array and hash references to NSArray and NSDictionary
>>> classes directly to
>>> greatly improve the readability of code:
>>
>> I'm not an ObjC front end maintainer and have no authority but one  
>> issue
>> I would have with this feature with gcc proper is that the ObjC front
>> end would have to learn about the semantics of "NSArray" and
>> "NSDictionary" which are actually not part of the language but part  
>> of
>> an external library.
>>
>> Now gcc already supports the -fconstant-string-class option as one  
>> way
>> to embed knowledge about an external library into an executable.   
>> But I
>> would like adding options with all these semantics from a foreign
>> library into the language implementation.
>>
>> Maybe this could be done more elegantly with plugin infrastructure  
>> that
>> that es being currently added: http://gcc.gnu.org/wiki/plugins
>>
>> Cheers,
>> David
>>
>>