The cfgetispeed() function shall extract the input baud rate from the
termios structure to which the termios_p argument points.
This function shall return exactly the value in the termios data
structure, without interpretation.
The term "baud" is used historically here, but is not technically
correct. This is properly "bits per second", which may not be the
same as baud. However, the term is used because of the historical usage and
The cfgetospeed(), cfgetispeed(), cfsetospeed(), and
cfsetispeed() functions do not take arguments as numbers, but rather as
symbolic names. There are two reasons for this:
Historically, numbers were not used because of the way the
rate was stored in the data structure. This is retained even though a
function is now used.
More importantly, only a limited set of possible rates is
at all portable, and this constrains the application to that set.
There is nothing to prevent an implementation accepting as an extension a number
(such as 126), and since the encoding of the Bxxx symbols is not specified,
this can be done to avoid introducing ambiguity.
Setting the input baud rate to zero was a mechanism to allow for split baud
rates. Clarifications in this volume of IEEE Std 1003.1-2001
have made it possible to determine whether split rates are supported and to
support them without having to treat zero as a special case. Since this
functionality is also confusing, it has been declared obsolescent. The 0
argument referred to is the literal constant 0, not the symbolic constant B0.
This volume of IEEE Std 1003.1-2001 does not preclude B0 from
being defined as the value 0; in fact, implementations would likely benefit
from the two being equivalent. This volume of
IEEE Std 1003.1-2001 does not fully specify whether the previous
cfsetispeed() value is retained after a tcgetattr() as the
actual value or as zero. Therefore, conforming applications should always set
both the input speed and output speed when setting either.
In historical implementations, the baud rate information is traditionally kept
in c_cflag. Applications should be written to presume that this might
be the case (and thus not blindly copy c_cflag), but not to rely on it
in case it is in some other field of the structure. Setting the c_cflag
field absolutely after setting a baud rate is a non-portable action because of
this. In general, the unused parts of the flag fields might be used by the
implementation and should not be blindly copied from the descriptions of one
terminal device to another.
Portions of this text are reprinted and reproduced in electronic form from IEEE
Std 1003.1, 2003 Edition, Standard for Information Technology -- Portable
Operating System Interface (POSIX), The Open Group Base Specifications Issue
6, Copyright (C) 2001-2003 by the Institute of Electrical and Electronics
Engineers, Inc and The Open Group. In the event of any discrepancy between
this version and the original IEEE and The Open Group Standard, the original
IEEE and The Open Group Standard is the referee document. The original
Standard can be obtained online at http://www.opengroup.org/unix/online.html