From rinehuls@access.digex.net Tue Sep 2 23:23:25 1997 Received: from access1.digex.net (qlrhmEbBUV1EY@access1.digex.net [205.197.245.192]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id XAA27553 for ; Tue, 2 Sep 1997 23:23:16 +0200 Received: from localhost (rinehuls@localhost) by access1.digex.net (8.8.4/8.8.4) with SMTP id RAA24216 for ; Tue, 2 Sep 1997 17:22:54 -0400 (EDT) Date: Tue, 2 Sep 1997 17:22:54 -0400 (EDT) From: "william c. rinehuls" To: sc22docs@dkuug.dk Subject: SC22 N2579 - WG22 Record of Responses on Defect Reports 01 through 18 - PCTE - AND LETTER BALLOT Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII ____________________ beginning of title page ___________________________ ISO/IEC JTC 1/SC22 Programming languages, their environments and system software interfaces Secretariat: U.S.A. (ANSI) ISO/IEC JTC 1/SC22 N2579 TITLE: WG22 Record of Responses for Defect Reports 01 through 18 for: ISO/IEC 13719-1 - Information technology - Portable Common Tool Environment (PCTE), Part 1; ISO/IEC 13719-2 - Information technology - Portable Common Tool Environment (PCTE), Part 2; and ISO/IEC 13719-3 - Information technology - Portable Common Tool Environment (PCTE0, Part 3 AND LETTER BALLOT DATE ASSIGNED: 1997-09-02 SOURCE: Secretariat, ISO/IEC JTC 1/SC22 BACKWARD POINTER: N/A DOCUMENT TYPE: Record of Responses for Defect Reports PROJECT NUMBER: JTC 1.22.47.1 STATUS: In accordance with SC22 N1236, non-responses to the letter ballot will be considered as agreement with the proposed record of responses. ACTION IDENTIFIER: ACT DUE DATE: 1998-01-07 DISTRIBUTION Text CROSS REFERENCE: SC22 N2425, N2426, N2427 DISTRIBUTION FORM: Open Address reply to: ISO/IEC JTC 1/SC22 Secretariat William C. Rinehuls 8457 Rushing Creek Court Springfield, VA 22153 USA Telephone: +1 (703) 912-9680 Fax: +1 (703) 912-2973 email: rinehuls@access.digex.net ____________________ end of title page; beginning of letter ballot _____ Attachment to JTC 1/SC22 N 2579 Circulation Date: 09-22-97 LETTER BALLOT FROM THE MEMBER BODY OF: ______________________________ On WG22 Proposed Record of Responses to Defect Reports 01 through 18 to: ISO/IEC 13719-1 - Information technology - Portable Common Tool Environment (PCTE), Part 1; ISO/IEC 13791-2 - Information technology - Portable Common Tool Environment (PCTE), Part 2; and ISO/IEC 13791-3 - Information technology - Portable Common Tool Environment (PCTE), Part 3 This Letter Ballot is to be returned by each "P" Member Body to the Secretariat of JTC 1/SC22 by JANUARY 7, 1998 ------------------------------------------------------------ ____ We agree with the Record of Responses or ____ We agree with the Record of Responses with the attached comments or ____ We do not agree with the Record of Responses for the technical reasons attached to this ballot or ____ We abstain from voting ("P" Member Bodies have an obligation to vote.) * CHECK WHICHEVER APPLIES. Name (please print) __________________ Signature (if mailed) ________________ Date: _________________ ____________ end of letter ballot; beginning of record of responses ___ Record of Response Issue 1 ISO/IEC JTC1/SC22/WG22 Defect Reports DR-001 to DR-018 inclusive ----------------------------------------------------------------------- Information technology - Portable Common Tool Environment (PCTE) ISO/IEC 13719 : 1995 August 1997 ----------------------------------------------------------------------- Introduction ------------ This document contains the responses to defects reported in the PCTE Standard ISO/IEC 13719, parts 1, 2, and 3, which led to no normative changes. The responses reflect the technical opinion of the experts of ISO-IEC/JTC1/SC22/WG22: PCTE, in conjunction with ECMA TC33. The full set of all comments with discussions and resolutions are in document SC22/WG22 N133. References to the parts of ISO/IEC 13719 are by paragraph number within subclause, as '(12)'. The notation 'EP-xxxx' (or EP-xxxx[y]) identifies the comment (and part of comment) in SC22/WG22 N133. ----------------------------------------------------------------------- Defect Report DR-001 (EP-4227) SUBJECT: Pcte_time almost unusable REFERENCES: ISO/IEC 13719-2/8.2.5 QUESTION: Paragraph (5) effectively makes the type Pcte_time a private type; however, the functions described are NOT provided by the Binding, thus making it impossible to set attributes to 'real' dates, or to read attribute values as 'real' dates. The definition of type Pcte_time as the type time_t is in itself somewhat suspect, as it has implications that the values are actually encoded as the number of seconds from some reference point, and hence that the standard C library functions timegm, gmtime, etc., may be used to manipulate values of this type. However, if this approach is used, a problem arises. The C/UNIX reference time is 1970-01-01T00:00:00Z (UTC), defined as a time_t value of 0, whereas the PCTE reference time is 1980-01-01T00:00:00Z, defined as the implementation-defined constant Pcte_reference_time. This means that if Pcte_times are converted into C times (by addition/subtraction of a suitable bias) so that the standard C functions can be used, the latest date which can be handled (given the use of 32-bit ints by C) is 1970-01-01T00:00:00Z + 2 ** 31 - 1 seconds which is 2038-01-19T03:14:07Z. This date is earlier than MAX_TIME_ATTRIBUTE, which is defined as being no earlier than 2044-12- 31T24:00:00Z. A suggested resolution is to make Pcte_time an implementation-defined type, and provide a set of operations upon it, comparable to those provided by the Ada Binding package PCTE.CALENDAR. The PCTE user should not be required to worry about the trivia (e.g. leap years, leap seconds, etc.) of converting between 'real' dates and Pcte_time values. RESPONSE: This is too difficult a change for the advantages gained. ----------------------------------------------------------------------- Defect Report DR-002 (EP-4348) SUBJECT: Missing errors in SDS_CREATE_DESIGNATION_LINK_TYPE REFERENCES: ISO/IEC 13719-1/10.2.5 QUESTION: In SDS_CREATE_DESIGNATION_LINK_TYPE: [1] Should the error LIMIT_WOULD_BE_EXCEEDED be raised when too many key_types are provided? [2] Should the error PCTE_LINK_TYPE_CATEGORY_IS_BAD be raised when the link to be created is not of category DESIGNATION? RESPONSE: [1] There is no limit and has been no limit to the number of key attributes that can be defined for a link. [2] No parameter specifies the category, since it is implied by the operation name. ----------------------------------------------------------------------- Defect Report DR-003 (EP-4350, EP-4401[11-16]) SUBJECT: Missing errors in SDS_CREATE_OBJECT_TYPE REFERENCES: ISO/IEC 13719-1/10.2.11 QUESTION: In SDS_CREATE_OBJECT_TYPE: [1] Should the error NO_PARENTS be raised when no parent is specified? [2] Should the error PARENT_TYPES_ARE_MULTIPLE be raised when a parent type occurs more than once in types? RESPONSE: [1] The case of no parents is covered by the error OBJECT_TYPE_WOULD_HAVE_NO_PARENT_TYPE (10.2.11(14)). [2] Multiple elements are specifically allowed in sequences representing unbounded sets in both the Ada and the C bindings - see 8.1.3(3) in both bindings. ----------------------------------------------------------------------- Defect Report DR-004 (EP-4351) SUBJECT: Missing errors in SDS_CREATE_RELATIONSHIP_TYPE REFERENCES: ISO/IEC 13719-1/10.2.12 QUESTION: In SDS_CREATE_RELATIONSHIP_TYPE should the error LIMIT_WOULD_BE_EXCEEDED be raised when too many key_types are provided? RESPONSE: there is no limit to the number of key attributes that can be defined for a link. (There is an effective limit implied by other constraints, but no explicit limit.) ----------------------------------------------------------------------- Defect Report DR-005 (EP-4357) SUBJECT: Questions on SDS_REMOVE_TYPE REFERENCES: ISO/IEC 13719-1/10.2.23 QUESTION: In SDS_REMOVE_TYPE: [1] Can all access errors be implemented with a scope ATOMIC? [2] If the type object is to be actually deleted, can no security checks be performed on the related type objects (i.e. the parent types in case of a deleted object type, the key attribute types in case of a deleted link type and the enumeral types in case of an enumeration attribute type)? RESPONSE: [1] No, this implementation is wrong. DELETE is a composite permission. [2] No, these security checks must be observed. ----------------------------------------------------------------------- Defect Report DR-006 (EP-4358) SUBJECT: SDS Usage Operations REFERENCES: ISO/IEC 13719-1/10 QUESTION: The sds_xxx functions return full type name instead of a local name in output parameters. The sds_xxx functions accept full type names as input parameters provided that the SDS name part of the full type names designates the same SDS than the "sds" parameter. RESPONSE: This is an implementation issue and does not affect the Standard. ----------------------------------------------------------------------- Defect Report DR-007 (EP-4369[2]) SUBJECT: Limit checks in PROCESS_CREATE REFERENCES: ISO/IEC 13719-1/13.2.1 QUESTION: Can the operation PROCESS_CREATE not check that the limits MAX_PROCESSES_PER_USER and MAX_PROCESSES are not exceeded? RESPONSE No, this would be a significant change, and would mean that the limits MAX_PROCESSES and MAX_PROCESSES_PER_USER need not be observed by an implementation, which is undesirable. ----------------------------------------------------------------------- Defect Report DR-008 (EP-4374) SUBJECT: Discretionary checks in PROCESS_WAIT_FOR_ANY_CHILD REFERENCES: ISO/IEC 13719-1/13.2.17 QUESTION: Need the operation PROCESS_WAIT_FOR_ANY_CHILD check the discretionary permission WRITE_ATTRIBUTES on the terminated child process? RESPONSE Yes, this is an essential check, and there seems no reason to omit it. ----------------------------------------------------------------------- Defect Report DR-009 (EP-4375) SUBJECT: Redundant errors in PROCESS_WAIT_FOR_CHILD REFERENCES: ISO/IEC 13719-1/13.2.18 QUESTION: In PROCESS_WAIT_FOR_CHILD the errors PROCESS_HAS_NOT_GOT_REQUIRED_STATUS (if status of the specified process is READY) and PROCESS_IS_NOT_CHILD (if the specified process is not a child process of the caller) are returned instead of PROCESS_IS_NOT_TERMINABLE_CHILD. According to its definition, the error PCTE_IS_NOT_TERMINABLE_CHILD could be replaced by both errors PROCESS_IS_NOT_CHILD and PROCESS_HAS_NOT_GOT_REQUIRED_STATUS. The request have been made only in order to reduce the general number of error codes and I have no more strong argument in favour of its comments (in fact it is not a problem if the comment is rejected). RESPONSE: The only reason for the change would be to reduce the number of errors, and it is now too late to do this. For reasons of backward compatibility the error code values in the interface should not now change. Eliminating an error code will not enable it to be re-used, or to change the values of the errors which follow in the list in Part 2, 25.1. Any new errors should be placed at the end of the list. ----------------------------------------------------------------------- Defect Report DR-010 (EP-4377) SUBJECT: Resetting the working schema in PROCESS_SET_USER REFERENCES: ISO/IEC 13719-1/13.3.7 QUESTION: Must PROCESS_SET_USER reset the working schema of the caller to empty? RESPONSE: Yes, this has long been agreed and no counter-arguments have been made. ----------------------------------------------------------------------- Defect Report DR-011 (EP-4378, EP-4379) SUBJECT: Discretionary check in process operations REFERENCES: ISO/IEC 13719-1/13.5.1, 13.5.2, 13,5,5 QUESTION: Should the operations PROCESS_ADD_BREAKPOINT, PROCESS_CONTINUE, and PROCESS_REMOVE_BREAKPOINT check the discretionary permission WRITE_ATTRIBUTES on the specified child process (instead of WRITE_CONTENTS)? RESPONSE: WRITE_CONTENTS is closer to what is intended ----------------------------------------------------------------------- Defect Report DR-012 (EP-4380, EP-4381) SUBJECT: Questions on PROCESS_PEEK and PROCESS_POKE REFERENCES: ISO/IEC 13719-1/13.5.3, 13.5.4 QUESTION: [1] Can the operations PROCESS_PEEK and PROCESS_POKE only accept a process_data_size equal to sizeof(Pcte_integer)? [2] Should the operations PROCESS_PEEK and PROCESS_POKE check the discretionary permission WRITE_ATTRIBUTES on the specified child process (instead of READ_CONTENTS and WRITE_CONTENTS respectively)? RESPONSE: [1] We take it this is a C binding problem; however PROCESS_PEEK and PROCESS_POKE are meant to handle very small pieces of data, a byte or a word at a time, and the actual size returned by PROCESS_PEEK was determined in an implementation-defined way. [2] READ_CONTENTS and WRITE_CONTENTS are closer to what is intended ----------------------------------------------------------------------- Defect Report DR-014 (EP-4384) SUBJECT: Message queue concepts REFERENCES: ISO/IEC 13719-1/14.1 QUESTION: Is it allowed for the position numbers given to messages in message queues to be assigned on a per-PCTE server basis in a monotonically increasing way starting from 1 each time the PCTE server is started, i.e. the counter is not persistent across PCTE termination (even if the message queue objects are)? RESPONSE: Message queue contents are not persistent across workstation termination, see 18.1.6(14). ----------------------------------------------------------------------- Defect Report DR-015 (EP-4390[2], EP-4391[2]) SUBJECT: Redundant error in CONTENTS_COPY_FROM_FOREIGN_SYSTEM REFERENCES: ISO/IEC 13719-1/18.3.1, 18.3.2 QUESTION: In CONTENTS_COPY_FROM_FOREIGN_SYSTEM and CONTENTS_COPY_TO_FOREIGN_SYSTEM why are the errors FOREIGN_SYSTEM_IS_INACCESSIBLE (both operations) and FOREIGN_EXECUTION_IMAGE_IS_BEING_EXECUTED (latter operation only) needed - why not return the error FOREIGN_OBJECT_IS_INACCESSIBLE if the failure is due to a problem with/on the foreign system, whatever the problem is? RESPONSE: While the distinction between FOREIGN_SYSTEM_IS_INACCESSIBLE and FOREIGN_OBJECT_IS_INACCESSIBLE seems fairly clear, and one could argue that a foreign system may be accessible, but an object ostensibly residing on that system may not be accessible, and these two situations are distinguishable, on the other hand.it was felt that we cannot legislate for the behaviour of a foreign system and so should only have one error, which should be FOREIGN_OBJECT_IS_INACCESSIBLE. ----------------------------------------------------------------------- Defect Report DR-016 (EP-4394, EP-4395, EP-4396, EP-4397) SUBJECT: Question on PROGRAM_GROUP_ADD_MEMBER REFERENCES: ISO/IEC 13719-1/19.3.4, 19.3.5, 19.3.8, 19.3.9 QUESTION: In PROGRAM_GROUP_ADD_MEMBER, PROGRAM_GROUP_ADD_SUBGROUP, USER_GROUP_ADD_MEMBER, and USER_GROUP_ADD_SUBGROUP, can the key of the "program_member_of", "program_subgroup_of", "user_member_of", and "user_subgroup_of" link (respectively) be the group identifier (key of the "known_security_group" link from the security directory to group)? RESPONSE: Yes, this is an implementation choice. ----------------------------------------------------------------------- Defect Report DR-017 (EP-5006) SUBJECT: LINK_REFERENCE_SET REFERENCES: ISO/IEC 13719-1/23.3.8 QUESTION: In LINK_REFERENCE_SET, error LINK_NAME_AND_EVALUATION_POINT_ARE_INCONSISTENT(link_name, point) has been omitted. The error needs to be added to Appendix C. The text is: 'Link name /link_name/ has one of the forms A.B., A.1. or A.1 which require a preferred link type which is unavailable to this operation, and evaluation point /point/ is NOW.' RESPONSE: An internal link reference is only pre-evaluated. This is made clear by 23.1.2.3(18) and (23), which show that the error PREFERENCE_DOES_NOT_EXIST can occur during evaluation of an internal link reference. ----------------------------------------------------------------------- Defect Report DR-018 (EP-5026) SUBJECT: Identical errors REFERENCES: ISO/IEC 13719-1/C.4 QUESTION: OBJECT_TYPE_IS_NOT_VISIBLE is defined as the same as OBJECT_TYPE_IS_UNKNOWN. Only the latter is used as far as I can see in operations which have object type references (nominators). For consistency only the former should be used and all places where OBJECT_TYPE_IS_UNKNOWN occurs it should simply be deleted. RESPONSE: One error refers to references, the other to nominators. ____________________ end of SC22 N2579 ______________________________