From owner-sc22wg5@open-std.org Wed Mar 30 18:10:27 2011 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www2.open-std.org Received: by www2.open-std.org (Postfix, from userid 521) id 514DCC3BA00; Wed, 30 Mar 2011 18:10:27 +0200 (CET DST) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) by www2.open-std.org (Postfix) with ESMTP id 32203C178E4 for ; Wed, 30 Mar 2011 18:10:23 +0200 (CET DST) Received: from d01dlp02.pok.ibm.com (d01dlp02.pok.ibm.com [9.56.224.85]) by e7.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p2UFmp6l014156 for ; Wed, 30 Mar 2011 11:48:55 -0400 Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 04F876E8039 for ; Wed, 30 Mar 2011 12:10:22 -0400 (EDT) Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p2UGALGn203928 for ; Wed, 30 Mar 2011 12:10:21 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p2UGAKLa016429 for ; Wed, 30 Mar 2011 12:10:20 -0400 Received: from d25ml04.torolab.ibm.com (d25ml04.torolab.ibm.com [9.26.6.105]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p2UGAKdu016402; Wed, 30 Mar 2011 12:10:20 -0400 In-Reply-To: <20110326180217.D7297C178DA@www2.open-std.org> References: <20110303174947.DD0CAC3BA01@www2.open-std.org> <20110325193010.B3704C178DA@www2.open-std.org> <20110326180217.D7297C178DA@www2.open-std.org> To: fortran standards email list for J3 Cc: j3-bounces@j3-fortran.org, sc22wg5@open-std.org MIME-Version: 1.0 Subject: Re: (j3.2006) (SC22WG5.4421) WG informal ballot X-KeepSent: D1210F31:39F6C188-85257863:0058AC30; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.1 HF105 April 10, 2008 Message-ID: From: Jim Xia Date: Wed, 30 Mar 2011 12:10:19 -0400 X-MIMETrack: Serialize by Router on D25ML04/25/M/IBM(Release 8.5.1FP4|July 25, 2010) at 03/30/2011 12:10:20, Serialize complete at 03/30/2011 12:10:20 Content-Type: multipart/alternative; boundary="=_alternative 0058D56A85257863_=" X-Content-Scanned: Fidelis XPS MAILER Sender: owner-sc22wg5@open-std.org Precedence: bulk This is a multipart message in MIME format. --=_alternative 0058D56A85257863_= Content-Type: text/plain; charset="US-ASCII" Addition comments from IBM (C side people) 3.3.{3,4} Seems to indicate runtime or generated code should do deallocation. Note that in C if no stdlib is included and no C lib is linked, this force programs to link in a library that they didn't want. 5.2.2: base_addr: Says if the object has zero size the value is not NULL. However the C standard allows NULL return values from malloc(0). 5.2.2, 5.2.3: Was there a reason to allow any order for the middle elements? This seems to decrease portability between compilers. 5.2.4 p3 seems to conflict with 5.2.5.5 p7, should the 15 there not be the macro value? 5.2.5.5 p3 indicates that it can establish a C descriptor for an object or a subobject of it implying that even if the user wanted a descriptor for an object they could end up getting a descriptor for a subobject. 6.3 p3 Grammar error: "that are *of* assumed type". I think the first comment is serious enough to reconsider the requirement on INTENT(OUT) for allocatables. Thanks, Jim Xia Compiler Testing, X10 & XLF IBM Toronto Lab at 8200 Warden Ave, Markham, On, L6G 1C7 905-413-3444 --=_alternative 0058D56A85257863_= Content-Type: text/html; charset="US-ASCII"
Addition comments from IBM (C side people)


3.3.{3,4} Seems to indicate runtime or generated code should do deallocation. Note that in C if no stdlib is included and no C lib is linked, this force programs to link in a library that they didn't want.

5.2.2: base_addr: Says if the object has zero size the value is not NULL. However the C standard allows NULL return values from malloc(0).

5.2.2, 5.2.3: Was there a reason to allow any order for the middle elements? This seems to decrease portability between compilers.

5.2.4 p3 seems to conflict with 5.2.5.5 p7, should the 15 there not be the macro value?

5.2.5.5 p3 indicates that it can establish a C descriptor for an object or a subobject of it implying that even if the user wanted a descriptor for an object they could end up getting a descriptor for a subobject.

6.3 p3 Grammar error: "that are *of* assumed type".


I think the first comment is serious enough to reconsider the requirement on INTENT(OUT) for allocatables.


Thanks,

Jim Xia

Compiler Testing, X10 & XLF
IBM Toronto Lab at 8200 Warden Ave,
Markham, On, L6G 1C7
905-413-3444
 --=_alternative 0058D56A85257863_=--