Ada POSIX binding and several set of POSIX interfaces for IPC

I'm taking a look to the standard Ada POSIX binding, and the Florist implementation for GNAT. The aim is evaluating if a legacy application can be ported from its own use of pragma Import of the C POSIX functions to use the standard binding. The final objective is to be able to recompile the application in Solaris and Linux without source code changes. My doubt is about the several set of interfaces used in the UNIX tradition for Inter Process Communication features, like semaphores, message queues, etc. Florist is importing these C functions:

• Semaphores: sem_init sem_destroy sem_open sem_close sem_unlink sem_wait sem_trywait sem_post sem_getvalue
• Message queues: mq_close mq_getattr mq_notify mq_open mq_receive mq_send mq_setattr mq_unlink

While the application is importing these other sets: - Semaphores: semget semop semctl - Message queues: msgctl msgrcv msgsnd

Some sources defines the set used by the application as System V and not POSIX, while in others they are declared as standardized by IEEE Std 1003.1-2001, which apparently is POSIX.

My questions are:

• Are the "System V" sets really standardized by POSIX?
• If they are POSIX, why the standard Ada POSIX binding does not provide bindings to them? Are they "less POSIX" than the other interfaces?
• If I decide to port the application to Florist, what differences in behaviour should I take into account to prevent any regression? Would you recommend against it?

I did some research and found two relevant documents from the ISO working group dedicated to Ada. In document Initial Work Scope Summary for updating Ada POSIX Bindings IS 14519:2001 to POSIX Draft IS 9945:2008 and Ada 2005 there is a list of POSIX functions not currently supported by the Ada standard as possible expansion. The XSI functions (aka SysV IPC) are mentioned there. So they are not currently supported.

But they will not be in the near future, since the document Draft Minutes, Meeting #64 states that the update effort has been cancelled. So users should continue making our own interface to those POSIX C functions, I guess.