From derek@knosof.uucp Fri Dec 23 15:36:54 1994 Received: from eros.Britain.EU.net by dkuug.dk with SMTP id AA26253 (5.65c8/IDA-1.4.4j for ); Sat, 24 Dec 1994 13:23:34 +0100 Received: from pyra.co.uk by eros.britain.eu.net with UUCP id ; Sat, 24 Dec 1994 12:23:32 +0000 Received: by knosof.UUCP (anilla/UUCP-Project/rel-1.0/11-05-86) id AA11628; Fri, 23 Dec 94 15:36:54 GMT Date: Fri, 23 Dec 94 15:36:54 GMT From: derek@knosof.uucp (Derek M Jones) Message-Id: <9412231536.AA11628@knosof.UUCP> To: wg15@pyra.co.uk Subject: POSIX.5 comments X-Charset: ASCII X-Char-Esc: 29 Some comments on ISO/IEC DIS 14519-1 POSIX Ada Interfaces - Part 1 I was pleased to see that this document followed the style set by Pois.1. Consistent style is a great help to those people having to find their way around more than one Posix standard. The Modula-2 WD, N1631, could learn a lot from the Ada binding. Page 3 line 94 "When executed, an implementation of this standard shall not be erroneous, as defined by the Ada RM." Initially this sounds like a requirement that the implementation be written in Ada. Further reflection suggests that the authors are requiring that the implementation contain no bugs. An API defines a set of services. A particular implementation may contain bugs that provide services over and above those required by the standard. The authors are trying to tie down the semantics of a main (in the Ada sense) program. However, given that the RM itself does not try to specify that the predefined packages have no bugs they are going a bit far by having such a requirement for the Posix.5 API. Page 5 line 141 "A Strictly Conforming POSIX.5 application is an application that only requires the facilities described in this standard and the Ada RM." What are the facilities defined in the Ada RM? The entire Ada language? Or, perhaps just the predefined packages? The latter I think. The wording needs to be tightened up to say exactly which bits of the Ada RM are being referred to. Page 5, line 171 is not there. The UK are promoting the concept of Rigorous Conformance. Such an application conforms to the Posix API plus all of the language requirements in the appropriate language standard. The Modula-2 WD makes a reasonable stab at such a requirement, but botches it by confusing portability with conformance. Please add a definition for Rigorous Conformance to Posix.5. Placing the service interface into a package does not solve all global name clashing problems. A package also needs a name. I would suggest that all package names beginning with the letter sequence POSIX_ followed by one or more letters and/or digits be reserved for future use. There are a number of technically incorrect statements made about the C language in Annex B. The authors have confused the use made of the language by developers with requirements contained in the standard. At this late stage is not worth while getting involved in a discussion on the coding styles adopted by developers vs coding styles influenced by language design. derek