Future compatibility of QueueHandle_t and StaticQueue_t

Kernel
1

xQueueGenericCreateStatic() takes a parameter of type StaticQueue_t and then returns it as is (albeit initialized) as type QueueHandle_t

For example,
StaticQueue_t staticQueue;

 // Leaving out other parameters that are not of interest
 QueueHandle_t   hQueue = xQueueGenericCreateStatic( , , , &staticQueue, );

Currently, in the FreeRTOS implementation, &staticQueue and hQueue are pointing to the same address, same object.

My question is, is this behavior guaranteed into the future. Will the statically allocated StaticQueue_t object and the object returns by xQueueGenericCreateStatic always be one and the same.

Or, do we need to allocate another variable to take the return value from xQueueGenericCreateStatic and use that value in subsequent API calls.

May seem like a rather benign question, but having to allocate another 4 bytes per statically allocated semaphore is not desirable.

2

This is the current implementation and may or may not change in future. Therefore, to keep your code future proof, I’d suggest to store the return value in a variable of type QueueHandle_t and use it in subsequent API calls.

Thanks.