Passing a 32-bit struct into an 32-bit integer function argument - objective-c

Question

I have some straight C code in my Objective-C project. In one of the APIs I'm using, I can register for a callback with a function that takes an 32-bit integer parameter:
void Callback(Packet* packet, int32_t port);
I want to be able to send my callback two 16-bit ports instead of one 32-bit port. Naturally, I could just use bitwise operations, but I'd prefer something more explicit.
Here's my current solution with a union:
typedef struct {
int16_t port1;
int16_t port2;
} MultiPortStruct;
typedef union {
int32_t port;
MultiPortStruct portStruct;
} MultiPortAdaptor;
In the sender:
void registerCallback(int16_t port1, int16_t port2) {
MultiPortAdaptor adaptor;
adaptor.portStruct.port1 = port1;
adaptor.portStruct.port2 = port2;
int32_t port = adaptor.port
RegisterAPICallback(&myCallback, port);
}
In the callback:
void myCallback(Packet* packet, int32_t port) {
MultiPortAdaptor adaptor;
adaptor.port = port;
int16_t port1 = adaptor.portStruct.port1;
int16_t port2 = adaptor.portStruct.port2;
// do stuff
}
Is this approach correct or are there problems with it? (For example: should I zero out the adaptor unions? Is it OK to access different members of the same union?) Is there a simpler way?
UPDATE:
OK, I'm convinced: even if doing this is possible, it's probably not a great idea. I've decided to simply use a set of functions to do the bitwise operations for me:
int32_t SubPortsToPort(int16_t port1, int16_t port2)
int16_t PortToSubPort1(int32_t port)
int16_t PortToSubPort2(int32_t port)
So now all I have to do is this:
void registerCallback(int16_t port1, int16_t port2) {
int32_t port = SubPortsToPort(port1, port2);
RegisterAPICallback(&myCallback, port);
}
And in the callback:
void myCallback(Packet* packet, int32_t port) {
int16_t port1 = PortToSubPort1(port);
int16_t port2 = PortToSubPort2(port);
// do stuff
}
Less code, less worries!

Answer 1

First it is OK to store into one member and read from another member of the same union provided you only read bytes you have written - any others have unspecified values.
The issue with what you are doing is the possible introduction by the compiler of padding between fields, which would destroy your carefully arranged overlap. With current compilers & cpu architectures you will probably be OK, but there is no need to leave it to chance as there are a number of ways to fix the alignment of fields.
The simplest, though compiler dependent, method is to use the packed attribute:
typedef struct __attribute((packed))
{
int16_t port1;
int16_t port2;
} MultiPortStruct;
This simply instructs the compiler not to add any padding, so the above will always be 32-bits even on architectures which use, say, 4-byte alignment for 2-byte values.
This attribute is supported by Clang, GCC & LLVM (maybe not all versions?) - the compiler will tell you if it doesn't. If you are using a compiler which does not support the attribute (or an equivalent one) then you can look into using the C language _Alignof and _Alignas features.
HTH

Answer 2

With the "struct in a union trick" you have to take care, because the structure members can be padded:
There may be unnamed padding within a structure object, but not at its
beginning.
ISO/IEC 9899:TC3, 6.7.2.1 – 13
Therefore, …
typedef struct {
int16_t port1;
int16_t port2;
} MultiPortStruct;
… can have a layout as …
typedef struct {
int32_t port1;
int32_t port2;
} MultiPortStruct;
… if the implementation likes that.
So the overlay in the union will not work, even this is not very likely.
It would be similar with bitfields:
typedef struct {
int port1:16;
int port2:16;
} MultiPortStruct;
This is, because the compiler has to put the following bitfield into the same unit, if it fits, but can chose the unit.
An implementation may allocate any addressable storage unit large enough to hold a bit- field. If enough space remains, a bit-field that immediately follows another bit-field in a structure shall be packed into adjacent bits of the same unit.
ibidem, 6.7.2.1 – 10
Therefore, it is theoretically possible, that an implementation choses int16 as allocation unit and places padding between the fields, even this makes no sense and is very unlikely.
As mentioned in the comment, there is nothing wrong with bitfields.

Answer 3

As others said, a struct might have padding (though unlikely). Another approach that would at least not have internal padding would be
typedef struct {
int16_t port[2];
} MultiPortStruct;
arrays never have internal padding and the first field of a struct is always at its start. Now theoretically this still could have padding at the end, so you should check with something like
_Static_assert(sizeof(MultiPortStruct)==2*sizeof(int16_t));