From ajosey@rdg.opengroup.org Tue Nov 18 15:16:07 1997 Received: from mailgate.rdg.opengroup.org (mailgate.rdg.opengroup.org [192.153.166.4]) by dkuug.dk (8.6.12/8.6.12) with SMTP id PAA09656 for ; Tue, 18 Nov 1997 15:15:59 +0100 Received: by mailgate.rdg.opengroup.org; id AA00858; Tue, 18 Nov 1997 14:16:42 GMT Message-Id: <9711181416.AA00858@mailgate.rdg.opengroup.org> Received: from mailhome [192.153.166.5] by mailgate.rdg.opengroup.org via smtpd ; Tue Nov 18 14:16 GMT 1997 Received: by mailhome.rdg.opengroup.org (1.36.108.10/16.2) id AA26163; Tue, 18 Nov 1997 14:10:01 GMT From: ajosey@rdg.opengroup.org (Andrew Josey) Date: Tue, 18 Nov 1997 14:10:01 +0000 Reply-To: ajosey@rdg.opengroup.org (Andrew Josey) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: sc22wg15@dkuug.dk Subject: IS 9945-1 Defect reports Attached are two recent defect reports for IS 9945-1 (references IS9945-1#82,#83,#84). Please note that these predate the switch to using Form 14 for PASC interps, but i have attached a WG15 status block to each one to assist. The status block will need completing by the WG15 PE. best regards Andrew WG15 Status Block: ------------------------------------------------------------------------ 1 Defect report number: IS9945-1#81 2 Submitter: IEEE PASC November 18 1997 3 Addressed to: JTC1/SC22 /WG15 editor's group on IS 9945-1 4 WG secretariat: ------------------------------------------------------------------------ 5 Date circulated by WG secretariat: 6 Deadline on response from editor: 7 Defect Report concerning (number and title of International Standard or DIS final text): IS 9945-1 8 Qualifier (e.g. error, omission, clarification required): clarification required 9 References in document (e.g. page, clause, figure, and/or table numbers): Relevant Sections: 7.2.1.2 10 Nature of defect (complete, concise explanation of the perceived problem): See attached ------------------------------------------------------------------------ 11 Solution proposed by the submitter (optional): None. ------------------------------------------------------------------------ 12 Editor's response (any material proposed for processing as a technical corrigendum to, an amendment to, or a commentary on the International Standard or DIS final text is attached separately to this completed report): See interpretation response attached _____________________________________________________________________________ PASC Interpretation reference 1003.1-90 #81 _____________________________________________________________________________ Interpretation Number: XXXX Topic: Relevant Sections: 7.2.1.2 Interpretation Request: ----------------------- Date: Sat, 22 Feb 1997 10:33:17 -0800 From: Chuck Karish Dear Standards Board: I would like to request an official, binding interpretation from the IEEE concerning the following point in subclause 7.2.1.2 of IEEE Std 1003.1-1990 (POSIX.1; unchanged in 1003.1-1996): Does POSIX.1 require that tcsetattr(fildes, TCSANOW, termios_p) preserve data that may have been received by the serial communications port but not yet processed and placed in the input queue? My reading of the Standard is that POSIX.1 is silent as to whether the data are preserved. This means that the effect on unprocessed input is unspecified, so a conforming implementation can discard the data. The critical specifications are: (1) If optional_actions is TCSANOW, the change shall occur immediately. (2) If optional_actions is TCSADRAIN, the change shall occur after all output written to fildes has been transmitted. This function should be used when changing parameters that affect output. (3) If optional_actions is TCSAFLUSH, the change shall occur after all output written to the object referred to by fildes has been transmitted, and all input that has been received, but not read, shall be discarded before the change is made. (1002.1-1990 p. 143, 144; subclause 7.2.1.2) (Questions in the elaboration below are meant to be rhetorical. They are not meant to request specific interpretations.) The descriptions focus largely on output. This is because output is under the system's control to a much greater extent than is input. The description of tcflow(), for example, has a corresponding asymmetry, in that the system is required to directly control output flow but only to send START and STOP out on the serial line to request that the remote system control input flow. Consider the case of a serial port that has an input buffer that holds raw input, to await processing in batches. This is an attractive architecture because it can greatly reduce the number of interrupts needed to service input on the port. What should happen to this buffered raw input when tcsetattr(fildes, TCSANOW, termios_p) is called? If the newly-set parameters include any changes to the input processing mode, the result of input processing on a system with such buffers could be different from what would be placed in the input queue by an implementation that does not buffer unprocessed data. Things are even worse for a character that has been only partly received from the transmission line by the serial hardware when the interface is reset. There is no unique correct way to process such data, and in many situations the data will be irretrievably corrupted. My feeling is that the TCSANOW optional action means "Make the change right now, no matter what happens to the data in transit". Tools are provided to allow the programmer to trade responsiveness for data integrity for output data. No such facilities and no corresponding guarantees are provided for input, because the problem is fundamentally difficult. It's impossible for the system to know what is about to arrive from the incoming serial connection. Thank you for your attention to this issue. Interpretation response ------------------------ The standard is silent on this issue, as to whether the data are preserved , and as such no conformance distinction can be made between different implementations. Rationale ------------- None. Forwarded to Interpretations group: 23 Feb 1997 Proposed resolution: 15 October 1997 Finalised: 18 November 1997 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WG15 Status Block: ------------------------------------------------------------------------ 1 Defect report number: IS9945-1#82 2 Submitter: IEEE PASC November 18 1997 3 Addressed to: JTC1/SC22 /WG15 editor's group on IS 9945-1 4 WG secretariat: ------------------------------------------------------------------------ 5 Date circulated by WG secretariat: 6 Deadline on response from editor: 7 Defect Report concerning (number and title of International Standard or DIS final text): IS 9945-1 8 Qualifier (e.g. error, omission, clarification required): clarification required 9 References in document (e.g. page, clause, figure, and/or table numbers): Relevant Sections: 7.1.3.2 10 Nature of defect (complete, concise explanation of the perceived problem): See attached ------------------------------------------------------------------------ 11 Solution proposed by the submitter (optional): None. ------------------------------------------------------------------------ 12 Editor's response (any material proposed for processing as a technical corrigendum to, an amendment to, or a commentary on the International Standard or DIS final text is attached separately to this completed report): See interpretation response attached _____________________________________________________________________________ PASC Interpretation reference 1003.1-90 #82 _____________________________________________________________________________ Interpretation Number: XXXX Topic: cfgetispeed and cfsetispeed Relevant Sections: 7.1.3.2 Interpretation Request: ----------------------- Date: Fri, 13 Jun 1997 13:12:46 -0400 From: Ted Baker IEEE Std 1003.1-1990 Interpretation Request Section 7.1.3.2 defines the beavior of the cgetispeed and cfsetispeed functions, as follows: | The cfsetispeed() function shall set the input baud rate stored in | the termios structure to which termios_p points. | The cfgetispeed() function shall return the input baud rate stored in | the termios structure to which termios_p points. >From this, one would expect that the following code would result in the value of speed being set to X, if none of the function calls return -1. | if (cfsetispeed(&termios_p, X) == -1) | printf ("cfsetispeed error %d\n", errno); | if ((speed = cfgetispeed (&termios_p)) == -1) | printf ("cfgetispeed error %d\n", errno); Now, 7.1.3.2 also says | ... It is unspecified whether these return an error if an unsupported | baud rate is set. So, one might conjecture that cfsetispeed or cfgetispeed might quietly fail for some values of X, but this behavior is only allowed if the baud rate X is "unsupported". The term "unsupported baud rate" is also used in 7.2.1.4, which says that tcsetarr() shall return -1 and set errno to EINVAL if "...an attempt was made to change an attribute represented in the termios structure to an unsupported value." Thus, if the baud rate X is unsupported, the following call to tcsetattr should return -1, if the input baud rate in termios_p is X. | if (tcsetattr(2, TCSANOW, &termios_p) == -1) | printf ("tcsetattr error %d\n", errno); In particular, consider the following program. | #define _POSIX_SOURCE | #include | #include | #include | | void main(){ | speed_t speed = 99; | struct termios termios_p; | printf("B0: %d\n", B0); | if (tcgetattr(2, &termios_p) == -1) | printf ("tcgetattr error %d\n", errno); | if ((speed = cfgetispeed (&termios_p)) == -1) | printf ("cfgetispeed error %d\n", errno); | printf("speed: %d\n", speed); | if (tcsetattr(2, TCSANOW, &termios_p) == -1) | printf ("tcsetattr error %d\n", errno); | if (cfsetispeed(&termios_p, B0) == -1) | printf ("cfsetispeed error %d\n", errno); | if ((speed = cfgetispeed (&termios_p)) == -1) | printf ("cfgetispeed error %d\n", errno); | printf("speed: %d\n", speed); | } Working through it step by step, we have: | #define _POSIX_SOURCE | #include | #include | #include | | void main(){ | speed_t speed = 99; | struct termios termios_p; | printf("B0: %d\n", B0); If this puts out "B0 : 0", we know B0 = 0. | if (tcgetattr(2, &termios_p) == -1) | printf ("tcgetattr error %d\n", errno); If this succeeds, we know filedescriptor 2 is valid for use with tcgetattr. | if ((speed = cfgetispeed (&termios_p)) == -1) | printf ("cfgetispeed error %d\n", errno); If this returns normally we know speed contains the input baud rate stored in termios_p, or else that baud rate value is unsupported. | printf("speed: %d\n", speed); If this prints out "speed: 0", we know the input baud rate stored in termios_p is 0. | if (tcsetattr(2, TCSANOW, &termios_p) == -1) | printf ("tcsetattr error %d\n", errno); If this returns normally, we know that the values specified in termios_p are supported. | if (cfsetispeed(&termios_p, B0) == -1) | printf ("cfsetispeed error %d\n", errno); If this returns normally we know the input baud rate value stored in termios_p is B0, or else that baud rate value is unsupported. | if ((speed = cfgetispeed (&termios_p)) == -1) | printf ("cfgetispeed error %d\n", errno); If this returns normally we know speed contains the input baud rate value stored in termios_p, or else that baud rate value is unsupported. | printf("speed: %d\n", speed); This should print out "speed: 0" if all of the calls above succeeded, and B0 = 0, and 0 is a supported baud rate value. | } In other words, the following output would be incorrect. B0: 0 speed: 0 speed: 13 Note: This interpretation request also applies to 1003.1-1993 and 1003.1-1995, as the specifications in question do not appear to have changed between versions. Interpretation response ------------------------ The implied question is, is an implementation that returns these values conforming. The response is yes. The standard clearly states that B0 is a special value, and that the value set in the structure by cfsetispeed() is not required to be returned "as is" by a call to cfgetispeed(). Rationale ------------- None. Forwarded to Interpretations group: 14 Jun 1997 Proposed resolution : 15 October 1997 Finalised: 18 November 1997