# cfgetispeed

## PROLOG



           This manual page is part of the POSIX Programmer's Manual.  The
           Linux implementation of this interface may differ (consult the
           corresponding Linux manual page for details of Linux behavior), or
           the interface may not be implemented on Linux.
    


## NAME



           cfgetispeed — get input baud rate
    


## SYNOPSIS



           #include <termios.h>
    
           speed_t cfgetispeed(const struct termios *_termios_p_);
    


## DESCRIPTION



           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.
    


## RETURN VALUE



           Upon successful completion, _cfgetispeed_() shall return a value of
           type **speed_t** representing the input baud rate.
    


## ERRORS



           No errors are defined.
    
           _The following sections are informative._
    


## EXAMPLES



           None.
    


## APPLICATION USAGE



           None.
    


## RATIONALE



           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 understanding.
    
           The _cfgetospeed_(), _cfgetispeed_(), _cfsetospeed_(), and _cfsetispeed_()
           functions do not take arguments as numbers, but rather as symbolic
           names. There are two reasons for this:
    
            1. 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.
    
            2. 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 POSIX.1‐2017
           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
           POSIX.1‐2017 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 POSIX.1‐2017 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.
    


## FUTURE DIRECTIONS



           None.
    


* * *