CFGETISPEED(3P)

🫶 PROLOG

okay bestie, real talk before we even start 💅 this page is part of the POSIX Programmer's Manual (that's the manual name, keep it in your notes). But — and this is the important part — the Linux implementation of this interface may differ, so go check the corresponding Linux manual page for the deets on Linux behavior. Or, plot twist, the interface might not even be implemented on Linux at all. 🙈 so don't come for me if it's not there.

---

✨ NAME ✨

cfgetispeed — get input baud rate 👑

---

🌸 SYNOPSIS 🌸

#include <termios.h>

speed_t cfgetispeed(const struct termios *termios_p);

---

💖 DESCRIPTION 💖

so cfgetispeed() shall extract the input baud rate from the termios structure that the termios_p argument points at. that's it. that's the job. 💅

and the way this function is giving exactly the value sitting in the termios data structure — no interpretation, no vibes-based reinterpreting, nothing. raw value, periodt.

---

⭐ RETURN VALUE ⭐

upon successful completion (slay), cfgetispeed() shall return a value of type speed_t representing the input baud rate. 🎀

---

🦋 ERRORS 🦋

no errors are defined. not a single one. she simply does not miss. ✨

heads up though: the following sections are informative. 👀

---

🌈 EXAMPLES 🌈

None. (bestie there is literally nothing here, I'm as disappointed as you are 😭)

---

🎀 APPLICATION USAGE 🎀

None. (again!! nothing!! the void!! 💀)

---

👑 RATIONALE 👑

okay this is the juicy part, grab a snack 🍓

the term "baud" is used here historically, but ngl it's not technically correct. what this actually means is "bits per second", which may not be the same thing as baud. but the term stuck around because of historical usage and understanding. iykyk. 💜

so the functions cfgetospeed(), cfgetispeed(), cfsetospeed(), and cfsetispeed() do not take arguments as numbers — they take them as symbolic names. and there are two reasons for that:

1. Historically, numbers weren't 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.

and there is nothing to prevent an implementation from accepting as an extension a number (like 126, for example), and since the encoding of the Bxxx symbols is not specified, this can be done to avoid introducing ambiguity. so it's giving "we left the door open on purpose." 🚪✨

now, 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. but since this functionality is also confusing, it has been declared obsolescent. ⚠️

and listen carefully: 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. like, both. every time. no shortcuts. 🫶

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's 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.

---

💜 SEE ALSO 💜

• cfgetospeed()
• cfsetispeed()
• cfsetospeed()
• tcgetattr()

and also the Base Definitions volume of POSIX.1‐2017, Chapter 11, General Terminal Interface, <termios.h> — go read it, it's iconic, no cap 📚✨

---

🌸 COPYRIGHT 🌸

Portions of this text are reprinted and reproduced in electronic form from IEEE Std 1003.1-2017, Standard for Information Technology -- Portable Operating System Interface (POSIX), The Open Group Base Specifications Issue 7, 2018 Edition, Copyright (C) 2018 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 .

Any typographical or formatting errors that appear in this page are most likely to have been introduced during the conversion of the source files to man page format. To report such errors, see https://www.kernel.org/doc/man-pages/reporting_bugs.html .

---

and that's the whole page bestie!! 🫶 this little manual page is brought to you by IEEE/The Open Group, dated 2017 — shoutout to the CFGETISPEED(3P) girlies, she ate and left no crumbs 💅✨ bye!! 🎀🦋