<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 6, 2015 at 7:40 AM, Laszlo Nagy <span dir="ltr"><<a href="mailto:rizsotto.mailinglist@gmail.com" target="_blank">rizsotto.mailinglist@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">hi Mehmet,<div><br></div><div>thanks for your message. you might be right, but i have other experiences. let me give you a few examples...</div><div><br></div><div>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.<br></div><div><br></div><div>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. ;) thanks for your feedback!</div><div><br></div><div>regards,</div><div>Laszlo</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 6, 2015 at 9:28 AM, Mehmet Erol Sanliturk <span dir="ltr"><<a href="mailto:m.e.sanliturk@gmail.com" target="_blank">m.e.sanliturk@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Thu, Mar 5, 2015 at 7:25 PM, Laszlo Nagy <span dir="ltr"><<a href="mailto:rizsotto.mailinglist@gmail.com" target="_blank">rizsotto.mailinglist@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr">hi there,<div><br></div><div>i am wondering that, is there such a tool which does language (or standard) conformance checking?</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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! ;)</div><div><br></div><div>regards,</div><div>Laszlo</div></div>
<br></div></div>_______________________________________________<br></blockquote></div><br><br><br></div><div class="gmail_extra">Assume , in different operating systems , there is the same compiler , for example , Clang 3.5.1 .<br></div><div class="gmail_extra"><br>Is compiling with , for example , -sdt=C99 , in one operating system , not sufficient for detecting incompatibilities with standard C99 ?<br><br><br></div><div class="gmail_extra">Thank you very much .<span><font color="#888888"><br><br><br></font></span></div><span><font color="#888888"><div class="gmail_extra">Mehmet Erol Sanliturk<br><br><br></div><div class="gmail_extra"><br></div></font></span></div>
</blockquote></div><br></div>
</blockquote></div><br><br><br><br></div><div class="gmail_extra">In standards , some parts are left to "Implementation dependent" . One of the most important incompatibilities come from such parts .<br><br></div><div class="gmail_extra">To obtain a "good" portability , such points should be considered and be avoided as much as possible .<br><br></div><div class="gmail_extra">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 .<br><br></div><div class="gmail_extra">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 .<br></div><div class="gmail_extra">If a group of compilers are used in that way , it is very likely that differences will be reduced as much as possible .<br><br><br></div><div class="gmail_extra">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 .<br><br></div><div class="gmail_extra">To reduce the portability difficulties , one of the ways may be to use parts solely handling operating systems or compiler dependencies .<br><br></div><div class="gmail_extra">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 .<br><br></div><div class="gmail_extra">It is possible to use "ifdef os ..." statements in every call point and use relevant call statements .<br></div><div class="gmail_extra">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 .<br><br><br></div><div class="gmail_extra">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" .<br><br><br></div><div class="gmail_extra">In contrary to Algol 68 , the Fortran defined its rules as complete as possible . Acceptance was very high and still it is in use .<br><br><br></div><div class="gmail_extra"> 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" .<br><br><br></div><div class="gmail_extra">Thank you very much .<br><br><br></div><div class="gmail_extra">Mehmet Erol Sanliturk<br><br><br></div></div>