[cfe-dev] language, standard conformance test

[Mehmet Erol Sanliturk]

On Fri, Mar 6, 2015 at 7:40 AM, Laszlo Nagy <rizsotto.mailinglist at gmail.com>
wrote:

> 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. ;) thanks for your feedback!
>
> regards,
> Laszlo
>
> On Fri, Mar 6, 2015 at 9:28 AM, Mehmet Erol Sanliturk <
> m.e.sanliturk at gmail.com> wrote:
>
>>
>>
>> On Thu, Mar 5, 2015 at 7:25 PM, Laszlo Nagy <
>> rizsotto.mailinglist at gmail.com> wrote:
>>
>>> 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! ;)
>>>
>>> regards,
>>> Laszlo
>>>
>>> _______________________________________________
>>>
>>
>>
>>
>> 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
>>
>>
>>
>>
>



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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150306/ecebe0cd/attachment.html>