Re: [patch] pragma for __attribute__ ((__ms_struct__))

[David Ayers <d dot ayers at inode dot at>]

Eric Christopher schrieb:
> 
> On Apr 28, 2006, at 10:46 AM, Andrew Pinski wrote:
> 
>>>
>>>
>>> On Apr 28, 2006, at 8:05 AM, Timothy J. Wood wrote:
>>>
>>> Let me be more specific, there's no MS ObjC compiler and therefore
>>> nothing to attempt to be compatible with.
>>
>>
>> Does that even matter?  We are talking about GCC support in general.
>> So if someone tries to use Distant Objects with the structs, it will
>> just fail silently.  Maybe make @encode warn about structs which
>> don't have the normal ABI is better, I don't know.
> 
> 
> I think I'd have to dig up an ObjC standard to understand what you  just
> said.
> 
> Or at least a pointer to the language. Got one?
Please have a look at:

http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/

specifically:

http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/Articles/chapter_5_section_7.html

but also related to the previous chapters on forwarding and remote
messaging.

Also the comments in libobjc/encoding.c should fill in some details.

In effect the @encode:ing tells describes the data layout that follows.
 They are used for persistent archives (like the old nib file formats)
and remote messaging.  In GNUstep we have DO working between different
platforms where each platform is responsible to supply the correct
encoding information when data is encoded and to handle a given layout
based on the provide information as gracefully as it can.

So I guess we need to devise a test case by creating archives of
essentially the same data on platforms with differing ABI's and have
them decoded on every (supported) platform during the test suite run to
verify that the results are sane.

Andrew?  Is that about right?

Cheers,
David