I'm trying to write a POSIX compliant application in C. I know that I can use the C standard runtime library, the POSIX C library, and the list of POSIX compliant utilities. I am wondering if there are any other libraries which are guaranteed POSIX compliant and how to get a list of them. For instance, I take it that I cannot use cURL for my internet communications, but will have to use POSIX sockets only. However, I would be interested in knowing whether there are libraries not specifically part of the POSIX standard which can be counted upon to be POSIX compliant.

Thanks.

there is no list of libraries (as far as I know), but «system interfaces»: http://pubs.opengroup.org/onlinepubs...functions.html
(TOC: http://pubs.opengroup.org/onlinepubs/007904875/toc.htm)

Thanks, but what about cURL, zLib (gzip), openssl, etc.? For all I know, some of these useful libraries may claim POSIX compliance. I was hoping that there could be some way to find out rather than a lot of Googling. It will be very hard to find out that a library is NOT POSIX compliant by random Googling. Anything that is not POSIX compliant I will be forced to re-implement myself, so I have a big motive to be able to identify libraries which do claim POSIX compliance.

Those libs run well on POSIX-compatible systems, but POSIX does not include libs like zlib etc. because those are simply not part of the POSIX system definition. The links posted by Ygrex show you what POSIX is all about.

Expect libraries like curl, zlib, openssl etc. to be available on virtually any POSIX-compatible system, either in form of a distro package or at least easily installable by compiling the original sourcecode on that system. POSIX compatible basically means that Linux, *BSD (including Mac OS X), Solaris and a few others are on board. The only alien thing there is - as usual - Windows..

It would just make my life easier if some of those libraries would declare themselves POSIX compliant. It would save me from having to re-implement the pieces of them that I need. I am under strict orders to produce an absolutely POSIX compliant program.

Moved: This thread is more suitable in <Programming> and has been moved accordingly to help your thread/question get the exposure it deserves.

You also need to use the functions in a POSIX-compliant way (e.g. struct flock differs between Linux and FreeBSD,) and include the correct headers even if it compiles on your machine without doing so. You also need to keep in mind that some behaviors of POSIX and C functions only work on certain versions of libc (e.g. some of the GNU extensions for printf,) and certain system-call nuances will differ by operating system (e.g. you can put an advisory lock on a pipe on Linux but not on FreeBSD.)

Kevin Barry

Why do you think you need to reimplement ? Simply make sure the libraries call only POSIX-compliant functions. If not, rewrite only the non-compliant parts - I think you'll hardly find any.

All those libraries compile under Linux/Solaris/*BSD/MacOS/Windows - which most likely means they are POSIX-compliant.

How can I make sure that existing libraries call only POSIX compliant functions?

Also, "likely" isn't enough. In the cases where I've Googled some of these libraries, they haven't been claiming POSIX compliance. I'm afraid I cannot proceed with my current project based on a "probably." As for re-writing only the portions of a library which are not POSIX compliant, I agree that it's possible, but wouldn't it involve finding the source code and inspecting thousands of lines of (sometimes very opaque) code, and then re-doing and testing all non-compliant structures? Doing this for libxml2, zlib, libssl, etc., etc. seems almost as burdensome as re-creating the limited portions I need. I find it odd that there is no source that attempts to list which popular libraries are POSIX compliant.

You build a library and then you run on it 'ldd' to see what other libraries it calls and 'nm' to see names in it, including function names.

You the determine which function belong to standard libraries and see their manpages to check whether they are compliant or not.

For example, 'man fopen' gives me the following prompt:

- the 'p' in '3p' means 'POSIX'.

So you locate where 'fopen' is used and check whether it's used in POSIX-compliant way.

In the Linux version (i.e. '3' - not '3p') I see:

.

It is not odd - GNU autotools (you probably are familiar with 'configure' scripts) take care of this. Typically non-GUI stuff build equally well on all UNIX flavors.

Wow, thanks! That is some great advice, together with excellent and clear explanations.

I still wish, though, that I didn't feel like the first person in history to do this in the sense that there is no list as to what is compliant, what is partially compliant, and what is non-compliant.

If you start reading Linux manpage, you'll find that sometimes POSIX non-compliance is intentional and for good reasons. E.g. POSIX compliance would cause ambiguity or buggy code.

A standard is not sacred. For example, there were numerous language defects found in C++ and filed against the standard.

...

My gut feeling tells me that *BSD as a more direct descendant of UNIX should be more POSIX-compliant; OTOH, I talked to a guy who worked with bot Linux and *BSD and at the time (2-3 years ago) and according to him Linux overall worked better. He was using file locking, multi-threading, etc.

1 members found this post helpful.

There isn't any point making sure your dependencies are written in a POSIX-compliant way, as long as you know they can be built for the OSes you target. Invariably libc and the dynamic linker won't be written in POSIX-compliant code, yet you'll almost always have them as dependencies. The point of writing your code in a POSIX-compliant way is so it will compile and execute properly on a variety of systems, but sometimes it's useful to take advantage of OS-specific functionality when it's available (using #ifdef blocks to specify alternate code.)

Kevin Barry

For the present exercise, we're working on product which can be compiled and run on almost any Unixy system, both big and tiny. That's the goal.