I'm just commenting for emphasis, no disagreements. Below... On Thu, May 27, 2010 at 10:29 AM, Stewart, Robert <Robert.Stewart@sig.com> wrote:
vicente.botet wrote:
Rob Stewart wrote:
I don't see any type safety problems in my original or hybrid APIs.
The problem is that we don't know the endiannes of the types int32_t or long. This depends on the operation you have performed on your code. E.g.
Endianness is not part of the type, so referring to type safety mislead me.
int32_t wire(/* from wire */); long l1; long l2; to_big_endian(l1, l2); to_big_endian(l2, wire);
Yes, the point here is that 'wire' isn't really an int, is it? At least not a useful one (at least when the machine's order doesn't match the wire). Thus they should be distinct types.
With the typed endians this is not possible. big32_t wire(/* from wire */); long l1; long l2; l2=l1; // no endian change as both are native wire=l2; // conversion to big from native.
That's a sensible concern and reason to provide such types (without the operators) along with the less safe functions.
Yep, I think it would be great if we could always use big32_t, etc. But you know there will be times when you are handed predefined objects with ints (but not really) in them, etc. So less safe functions, including in-place functions, will be needed. And I also agree that the operators should be avoided. Tony