language, standard conformance test

hi there,

i am wondering that, is there such a tool which does language (or standard) conformance checking?

a tool which takes the source code of a project (and a compilation database) and report that the source code shall be compiled at least with compiler which can do for example, C99 and on an OS which does support POSIX.1-2001. or a more detailed report which says these function calls (source location provided) are require this level of standard conformance, and those are available on these platforms. or this and this function calls are obsolete in standard X and use some other call instead.

these kind of informations are there in the man pages, but have to check manually. and my endeavour in multi OS, portable C/C++ code was always with surprises. and a tool like this would have been useful for me in the past.

i am interested that tool is exists or not? or somebody planing to implement such? or any opinion why this kind of tool is not useful, and testing on real OS will be the ultimate solution every time, and that can’t be avoided. so, any thoughts are welcome! :wink:


Assume , in different operating systems , there is the same compiler , for
example , Clang 3.5.1 .

Is compiling with , for example , -sdt=C99 , in one operating system , not
sufficient for detecting incompatibilities with standard C99 ?

Thank you very much .

Mehmet Erol Sanliturk

hi Mehmet,

thanks for your message. you might be right, but i have other experiences. let me give you a few examples…

according to linux man pages, the system call ‘clock_gettime’ is POSIX.1-2001 conform. and it is available on Linux or FreeBSD, but it is not there on OSX… or ‘asprintf’ is a GNU extension, not in C or POSIX standards, but it is available on Linux, FreeBSD or OSX… some other GNU extension are implemented only in GNU libc, therefore available only on Linux.

so, as far as i see that standard conformity is depends on the OS libc rather than the compiler. so, i thought a tool can forecast these incompatibilities and can reason about it… but you are right, C standard compatibilities can be caught on a single platform already. maybe it is a bad idea, that’s why nobody had made it. :wink: thanks for your feedback!


In standards , some parts are left to "Implementation dependent" . One of
the most important incompatibilities come from such parts .

To obtain a "good" portability , such points should be considered and be
avoided as much as possible .

Another possibility is to set the same standard option in compilation and
use many compilers for the same source tree in the same operating system .
If that program is accepted as correct by many compilers , it means that
compiler dependent parts are not used within the same operating system .

Another approach may be to use an NFS server , then compile the same
program source tree from different client operating systems with the SAME
compiler kind such as Clang for its operating system to remedy differences .
If a group of compilers are used in that way , it is very likely that
differences will be reduced as much as possible .

Another difference source is operating system dependencies . These should
be handled by "ifdef os ..." statements because some features are very
different in different operating systems which they can not made equivalent

To reduce the portability difficulties , one of the ways may be to use
parts solely handling operating systems or compiler dependencies .

For example : Time : Assume in different operating systems , the time
routines are very different and your program is using a large number of
time routine calls .

It is possible to use "ifdef os ..." statements in every call point and use
relevant call statements .
OR write a time routine yourself with common parameters and call this
routine from where it is needed . Inside of that single routine use
relevant "ifdef os ..." statements , i.e. , collect operating systems
dependent , compiler dependent parts into such single routines and use your
routines from other places . In that way , you will need to customize a
small number of routines , instead of a large number of other routines .

Algol 68 was one of the best programming languages when it was designed .
The most important deficiency was the decision to leave input / output
"implementation dependent " . Due to this , no one of the implementation
was compatible to another implementation . This "feature" made the Algol 68
as "still born" .

In contrary to Algol 68 , the Fortran defined its rules as complete as
possible . Acceptance was very high and still it is in use .

One very unfortunate situation for the "Standards" are that they are NOT
"standard" : Leaving many parts as undefined because of effects of "LARGE"
ones for their own benefits , i.e. , design of standard are not based on
completely "Science" but mostly "Benefits" .

Thank you very much .

Mehmet Erol Sanliturk