gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [patch #6286] NSBezierPath encode/decode improperly implemented


From: David Ayers
Subject: Re: [patch #6286] NSBezierPath encode/decode improperly implemented
Date: Thu, 06 Dec 2007 09:55:52 +0100
User-agent: Mozilla Thunderbird 1.0.2 (X11/20070113)

Fred Kiefer schrieb:
> A few days ago I replied to a patch send in by Christopher Wojno:
> 
> Fred Kiefer wrote:
> 
>>Update of patch #6286 (project gnustep):
>>In your error message I can see that an NSKeyedArchiver gets used. As far as
>>I can see, your patch doesn't implement the missing keyed archiving for
>>NSBezierPath, so how does it help you?
>>
>>In my code NSBezierPathElement is always an enumeration, why would the
>>encoding stuff need the additional hint that it really is an enum? As far as I
>>can see there is no struct called NSBezierPathElement.
>>
> 
> 
> It turned out that it really makes a difference if we use
> @encode(NSBezierPathElement) or @encode(enum NSBezierPathElement). Could
> somebody explain this to me? Why isn't NSBezierPathElement resolved to
> an unsigned int?

Hello Fred,

an enum should be encoded as an int (as opposed to an unsigned int) on
most platforms (See NSComparisonResult for usage of negative values).
Yet there are platforms(/gcc options) for which small enums can be
stored in smaller signed base types.

But I do believe that:

typedef {
  VAL1,
  VAL2
} ENumType;

@encode(ENumType);
and
@encode(enum ENumType);

should always return the same string (on our platforms "i").

Cheers,
David




reply via email to

[Prev in Thread] Current Thread [Next in Thread]