JTC1/SC22
N2579
Date: Tue, 2 Sep 1997 17:22:54 -0400 (EDT)
From: "william c. rinehuls" <rinehuls@access.digex.net>
To: sc22docs@dkuug.dk
Subject: SC22 N2579 - WG22 Record of Responses on Defect Reports 01 through 18 - PCTE - AND LETTER BALLOT
____________________ 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 ______________________________