logo

oasis-root

Compiled tree of Oasis Linux based on own branch at <https://hacktivis.me/git/oasis/> git clone https://anongit.hacktivis.me/git/oasis-root.git

cfgetispeed.3p (4609B)

    

  1. '\" et
  2. .TH CFGETISPEED "3P" 2017 "IEEE/The Open Group" "POSIX Programmer's Manual"
  3. .\"
  4. .SH PROLOG
  5. This manual page is part of the POSIX Programmer's Manual.
  6. The Linux implementation of this interface may differ (consult
  7. the corresponding Linux manual page for details of Linux behavior),
  8. or the interface may not be implemented on Linux.
  9. .\"
  10. .SH NAME
  11. cfgetispeed
  12. \(em get input baud rate
  13. .SH SYNOPSIS
  14. .LP
  15. .nf
  16. #include <termios.h>
  17. .P
  18. speed_t cfgetispeed(const struct termios *\fItermios_p\fP);
  19. .fi
  20. .SH DESCRIPTION
  21. The
  22. \fIcfgetispeed\fR()
  23. function shall extract the input baud rate from the
  24. .BR termios
  25. structure to which the
  26. .IR termios_p
  27. argument points.
  28. .P
  29. This function shall return exactly the value in the
  30. .BR termios
  31. data structure, without interpretation.
  32. .SH "RETURN VALUE"
  33. Upon successful completion,
  34. \fIcfgetispeed\fR()
  35. shall return a value of type
  36. .BR speed_t
  37. representing the input baud rate.
  38. .SH ERRORS
  39. No errors are defined.
  40. .LP
  41. .IR "The following sections are informative."
  42. .SH EXAMPLES
  43. None.
  44. .SH "APPLICATION USAGE"
  45. None.
  46. .SH RATIONALE
  47. The term ``baud'' is used historically here, but is not technically
  48. correct. This is properly ``bits per second'', which may not be the
  49. same as baud. However, the term is used because of the historical
  50. usage and understanding.
  51. .P
  52. The
  53. \fIcfgetospeed\fR(),
  54. \fIcfgetispeed\fR(),
  55. \fIcfsetospeed\fR(),
  56. and
  57. \fIcfsetispeed\fR()
  58. functions do not take arguments as numbers, but rather as symbolic
  59. names. There are two reasons for this:
  60. .IP " 1." 4
  61. Historically, numbers were not used because of the way the rate was
  62. stored in the data structure. This is retained even though a
  63. function is now used.
  64. .IP " 2." 4
  65. More importantly, only a limited set of possible rates is at all
  66. portable, and this constrains the application to that set.
  67. .P
  68. There is nothing to prevent an implementation accepting as an extension
  69. a number (such as 126), and since the encoding of the Bxxx symbols is
  70. not specified, this can be done to avoid introducing ambiguity.
  71. .P
  72. Setting the input baud rate to zero was a mechanism to allow for split
  73. baud rates. Clarifications in this volume of POSIX.1\(hy2017 have made it possible to determine
  74. whether split rates are supported and to support them without having to
  75. treat zero as a special case. Since this functionality is also
  76. confusing, it has been declared obsolescent.
  77. The 0 argument referred to is the literal constant 0, not the symbolic
  78. constant B0. This volume of POSIX.1\(hy2017 does not preclude B0 from being defined as the value
  79. 0; in fact, implementations would likely benefit from the two being
  80. equivalent. This volume of POSIX.1\(hy2017 does not fully specify whether the previous
  81. \fIcfsetispeed\fR()
  82. value is retained after a
  83. \fItcgetattr\fR()
  84. as the actual value or as zero. Therefore, conforming applications should
  85. always set both the input speed and output speed when setting either.
  86. .P
  87. In historical implementations, the baud rate information is
  88. traditionally kept in
  89. .BR c_cflag .
  90. Applications should be written to presume that this might be the case
  91. (and thus not blindly copy
  92. .BR c_cflag ),
  93. but not to rely on it in case it is in some other field of the
  94. structure. Setting the
  95. .BR c_cflag
  96. field absolutely after setting a baud rate is a non-portable action
  97. because of this. In general, the unused parts of the flag fields might
  98. be used by the implementation and should not be blindly copied from the
  99. descriptions of one terminal device to another.
  100. .SH "FUTURE DIRECTIONS"
  101. None.
  102. .SH "SEE ALSO"
  103. .IR "\fIcfgetospeed\fR\^(\|)",
  104. .IR "\fIcfsetispeed\fR\^(\|)",
  105. .IR "\fIcfsetospeed\fR\^(\|)",
  106. .IR "\fItcgetattr\fR\^(\|)"
  107. .P
  108. The Base Definitions volume of POSIX.1\(hy2017,
  109. .IR "Chapter 11" ", " "General Terminal Interface",
  110. .IR "\fB<termios.h>\fP"
  111. .\"
  112. .SH COPYRIGHT
  113. Portions of this text are reprinted and reproduced in electronic form
  114. from IEEE Std 1003.1-2017, Standard for Information Technology
  115. -- Portable Operating System Interface (POSIX), The Open Group Base
  116. Specifications Issue 7, 2018 Edition,
  117. Copyright (C) 2018 by the Institute of
  118. Electrical and Electronics Engineers, Inc and The Open Group.
  119. In the event of any discrepancy between this version and the original IEEE and
  120. The Open Group Standard, the original IEEE and The Open Group Standard
  121. is the referee document. The original Standard can be obtained online at
  122. http://www.opengroup.org/unix/online.html .
  123. .PP
  124. Any typographical or formatting errors that appear
  125. in this page are most likely
  126. to have been introduced during the conversion of the source files to
  127. man page format. To report such errors, see
  128. https://www.kernel.org/doc/man-pages/reporting_bugs.html .