From rz48@rz.uni-karlsruhe.de Tue Jan 14 03:54:46 1997 Received: from nz11.rz.uni-karlsruhe.de (nz11.rz.uni-karlsruhe.de [129.13.64.7]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id DAA14981 for ; Tue, 14 Jan 1997 03:54:42 +0100 Message-Id: <199701140254.DAA14981@dkuug.dk> Received: from ry73.rz.uni-karlsruhe.de by nz11.rz.uni-karlsruhe.de with SMTP (PP); Tue, 14 Jan 1997 01:07:04 +0100 Received: by ry73.rz.uni-karlsruhe.de (1.38.193.4/16.2) id AA12749; Mon, 13 Jan 1997 18:04:39 +0100 Subject: N1237: Interoperability Technical Report To: sc22wg5@dkuug.dk, sc22wg5-interop@ncsa.uiuc.edu Date: Mon, 13 Jan 1997 18:04:39 +0100 (CET) From: hennecke@rz.uni-karlsruhe.de (Michael Hennecke) Reply-To: hennecke@rz.uni-karlsruhe.de (Michael Hennecke) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Length: 4077 The third draft of the Interoperability TR is now complete. It has document numbers WG5/N1237 and X3J3/97-108 and can be downloaded in PostScript / gzipped PostScript form from: http://www.uni-karlsruhe.de/~SC22WG5/TR-C/n1237.ps http://www.uni-karlsruhe.de/~SC22WG5/TR-C/n1237.ps.gz It will also be available on the usual ftp sites soon. This is a rather big revision of the previous draft, WG5/N1178 (X3J3/96-069), incorporating parts of the experiences and requirements formulated in WG5/N1235 (X3J3/97-107) Interoperability with C and Binding to POSIX.1 WG5/N1229 (X3J3/96-153) Support for C variable argument lists WG5/N1185 (X3J3/96-119) Discussion of MAP_TO and BIND interoperability and a large number of new features. The most important syntactic news are: * Support for two C pointer types: TYPE(C_CHAR_PTR) for char* and TYPE(C_VOID_PTR) for void*. These are types with PRIVATE components, operations include assignment, comparison to a C null pointer constant, C_ADDRESS, C_DEREFERENCE and C_INCREMENT. Function results may be of these types (!). This is a quite large portion of C pointer support, but I think that anything significantly ``lighter'' would not be enough to interface to most existing C code. * A PASS_BY spec for dummy arguments (as in HPF-2 but with only *one* level of pointer declarators) to indicate pass-by-reference, the default in BIND(C) interfaces being pass-by-value. * Support for C variable argument lists * Support for dummy procedures (actuals must be BIND(C) procedures) * optional PRAGMA strings in BIND and PASS_BY to specify implementation dependent details (is this enough, or do we need it in more places???) The most important semantic change (apart from the C pointer stuff) is the specification of what happens at a procedure reference. Section 3.4.2.1 has the important specs. In C all scalar arguments are passed strictly by value, and since the callee may modify its dummy argument without affecting the actual argument, this implies that a *COPY* of the actual must be passed. By requiring these semantics for all scalar arguments without PASS_BY("*"), and specifying that the copy is made like an assignment from actual-arg-type to dummy-arg-type, THE OLD MAP_TO CONTROVERSY HAS BEEN QUIETLY RESOLVED !!! With these semantics, INTEGER(C_SHORT) may be associated with INTEGER(C_LONG), or even with floating types. Since there is never a copy-back to the actual argument, this assignment mechanism cannot cause unwanted rounding problems like those pointed out by Henry for the (bi-directional) MAP_TO conversions. Note that with PASS_BY("*") and with arrays, it is still required that the types match exactly. Additionally, further restrictions are placed on the actual argument in this case because C_ADDRESS(actual-arg) is passed to the C procedure, with the expectation that C may modify the target --- which then should better not be a compiler-generated temporary. ************************************************************************ Since there is only a small evening session allocated to this TR at the February meeting in Las Vegas, I would appreciate to receive comments before that meeting, to be able to give responses at the meeting. ************************************************************************ Best regards, Michael PS: Sorry there are no programming examples in 3.4.1 and 3.4.2, I hope to bring some to the meeting... ====================================================================== Michael Hennecke http://www.uni-karlsruhe.de/~Michael.Hennecke/ ---------------------------------------------------------------------- University of Karlsruhe RFC822: hennecke@rz.uni-karlsruhe.de Computing Center (G20.21 R210) No longer on BITNET :-( Zirkel 2 * P.O. Box 69 80 Phone: +49 721 608-4862 D-76128 Karlsruhe Fax: +49 721 32550 ======================================================================