Regarding to portability, libporty defines each system as a set of features and parent systems. A system is assumed to inherit all features from all its parent systems. In other words, a system is a collection of features from other systems (parents) plus some extra features. This saves us from having to duplicate a lot of features. The current graph is (children -> parent form): Linux -> GNU GNU -> POSIX.1-2008, SVr4, 4.4BSD BSD -> 4.4BSD Solaris -> C89 SUSv2 -> C89 SVr4 -> SVr3 SVr3 -> SVr2 SVr2 -> SV SV -> V7 V7 4.4BSD -> 4.3BSD, C89 4.3BSD -> 4.2BSD 4.2BSD -> 3BSD 3BSD POSIX.1-2008 -> POSIX.1-2001 POSIX.1-2001 -> POSIX.1-1990 POSIX.1-1990 C99 -> C89 C89 (note: this list is compiled using standards(7) of the Linux Programmer's Manual) Example: usleep() is coming from 4.3BSD and standarized in POSIX.1-2001; using the above table we assume that because of 4.3BSD, it is also presend in 4.4BSD, and thus in the BSD meta-system; because of POSIX.1-2001, it is also supported by POSIX.1-2008 and then GNU and then Linux. However, assuming such inheritance of features is only the default behavior. There may be exceptions. In porty's call check rule, exceptions are handled by the @warnpresent and @notpresent directives. For example, bzero has the following present directives: @present 4.3BSD @warnpresnet POSIX.1-2001 @notpresent POSIX.1-2008 which means it is introduced by 4.3BSD but is obsolete in POSIX.1-2001 and does not present in POSIX.1-2008. Processing rule is: expand user provided "target systems list" into an "expanded target systems" list (where each list item includes its parents, recursively, but at the end, each item is listed only once). Then run the following rules, in order: 1. if all elements of the "target systems list" is on the "@present list", accept; when testing an element, expand it, and if any of the parent of the element is on the list, accept. 2. if any of the elements of the "expanded target system list" is on the "@warnpresent" list, accept and give a warning 3. if any item of the "target systems list" is on the "@notpresent list", reject with error If the user runs porty on a code calling bzero, the result will be, per target system combination: C89 -> rejected because of rule 1 C99 -> rejected not present in C99 POSIX.1-2001 -> accepted with a warning because of rule 2 POSIX.1-2008 -> rejected because of rule 3 4.3BSD -> accepted because of rule 1 SVr4 -> rejected because of rule 1; SVr4 is not on the list, its only child C89 neither. GNU -> accepted with a warning rule 1: 4.3BSD is child of GNU, thus accepted rule 2: GNU expands to have POSIX.1-2001 rule 3: no match, as POSIX.1-2008 is not explicitly included by the user 4.3BSD, SVr4 -> rejected rule 1: would accept for 4.3BSD, but the user also requested SVr4 The rules are set this way to make simple and common cases easy to describe on command line. For strictness, a simplified, common real-life model of relations would be (systems on the left are more portable): C89 > 4.4BSD,SVr4 > SVr4 > BSD > C99 > GNU In words: for extreme portability, the user should request C89. However, some essential calls are not in C89, and SVr4 more-or-less guarantees support on most ancient UNIX systems still in use, whereas BSD represents UNIX a decade later (but still back in the 90s). C99 is a reasonable choice for cross-platform software (that is, software running on the most common 3 desktop systems, ignoring systems older than a decade). At the end, GNU means "no portability", and the software compiles only on systems with gcc and GNU libc installed. A special but very useful case is "4.4BSD,SVr4", which would ensure the software works on both ancient UNIX systems and BSD systems. This is a bit more strict than just running on SVr4 or on 4.4BSD, but is preferred in the case when C89 is not enough. Please note: the aim of porty is to warn the user about _potential_ portability issues "offline", analyzing the code on a single host. In reality there are always unexpected special combinations on exotic systems (the user should use scconfig to find out actual setup of the target system). The database is assembled in a way that it will have more false negatives than false positives for an actual system, i.e. it will more often warn about a call that happens to be supported by an exotic target system then promise the call will work while it is not supported on the same exotic target.