Re: GCC 4.0 GetKeys() and BigEndianLong for Intel
Re: GCC 4.0 GetKeys() and BigEndianLong for Intel
- Subject: Re: GCC 4.0 GetKeys() and BigEndianLong for Intel
- From: "MacArthur, Ian (SELEX) (UK)" <email@hidden>
- Date: Thu, 16 Jun 2005 16:09:17 +0100
- Thread-topic: Xcode-users Digest, Vol 2, Issue 283
I rambled about:
> > I guess it's way to late to get it changed now, but that
> strikes me
> > as exactly the sort of thing that will be a pain.
> > There's no real reason *why* it has to be a struct rather
> than just
> > a long
Jonas replied:
> Well, it prevents you from forgetting to put byteswapping code in
> place. My guess is that it will save a lot more time in the long run
> than that it will cost.
No, I disagree. For various reasons, the code I have is already "endian-ness aware". But this particular example is a poor API implementation for two reasons, as I see it:
1- The "form" of the code is different in either case, for i386 you have to use
"theKeys[1].bigEndianValue"
whereas on ppc you just use
"theKeys[1]" to get at the same bit of data.
So it's not "symmetrical", if you see what I mean. It's untidy, particularly here, where the type stored in the struct is of the same size as the item it substitutes for, anyway.
2- There's no real reason the API couldn't return native byte order anyway for this sort of thing. Worse, there's probably code in the i386 port that's deliberatley putting it into the wrong order in the first place!
So surely it will cause more confusion than it prevents?
--
Ian
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden