LLROUND(3POSIX)

πŸ’– LLROUND β€” POSIX Programmer's Manual, section 3 πŸ’–

okay bestie, welcome to LLROUND(3POSIX), straight outta the POSIX Programmer's Manual. pull up a chair, grab a strawberry πŸ“, and let's get into it.

🫢 PROLOG 🫢

so like, first things first: this manual page is part of the POSIX Programmer's Manual. the Linux implementation of this interface may differ (pls consult the corresponding Linux manual page for the deets on Linux behavior), or β€” and this is the messy part β€” the interface might not even be implemented on Linux at all. πŸ™ˆ iykyk.


✨ NAME ✨

llround, llroundf, llroundl β€” round to nearest integer value. periodt. that's the whole vibe.

🌸 SYNOPSIS 🌸

#include <math.h>

long long llround(double x);
long long llroundf(float x);
long long llroundl(long double x);

three besties, three float types, one job. πŸ‘‘

πŸ¦‹ DESCRIPTION πŸ¦‹

okay so the functionality described on this reference page is aligned with the ISO C standard. any conflict between the requirements described here and the ISO C standard is unintentional β€” nobody's trying to start drama. this volume of POSIX.1‐2017 defers to the ISO C standard, no cap.

these functions shall round their argument to the nearest integer value, and here's the icon behavior: they round halfway cases away from zero, and they do it regardless of the current rounding direction. like, they don't care what the rounding direction thinks. main character energy fr fr. πŸ’…

and if you're the type of application that wants to check for error situations (valid, love that for you), here's the move: set errno to zero and call feclearexcept(FE_ALL_EXCEPT) before calling these functions. then on return, if errno is non-zero, or if fetestexcept(FE_INVALID | FE_DIVBYZERO | FE_OVERFLOW | FE_UNDERFLOW) is non-zero, then boom β€” an error has occurred. πŸ’€

πŸ”₯ RETURN VALUE πŸ”₯

upon successful completion, these functions shall return the rounded integer value. slay. ✨

but now the plot twists:

  • if x is NaN, a domain error shall occur, and an unspecified value is returned. 😭
  • if x is +Inf, a domain error shall occur and an unspecified value is returned. 😭
  • if x is -Inf, a domain error shall occur and an unspecified value is returned. 😭
  • if the correct value is positive and too large to represent as a long long, an unspecified value shall be returned. on systems that support the IEC 60559 Floating-Point option, a domain error shall occur; otherwise, a domain error may occur.
  • if the correct value is negative and too large to represent as a long long, an unspecified value shall be returned. on systems that support the IEC 60559 Floating-Point option, a domain error shall occur; otherwise, a domain error may occur.

πŸŽ€ ERRORS πŸŽ€

these functions shall fail if:

  • Domain Error β€” the x argument is NaN or Β±Inf, or the correct value is not representable as an integer.

if the integer expression (math_errhandling & MATH_ERRNO) is non-zero, then errno shall be set to [EDOM]. if the integer expression (math_errhandling & MATH_ERREXCEPT) is non-zero, then the invalid floating-point exception shall be raised. 🚨

these functions may fail if:

  • Domain Error β€” the correct value is not representable as an integer.

if the integer expression (math_errhandling & MATH_ERRNO) is non-zero, then errno shall be set to [EDOM]. if the integer expression (math_errhandling & MATH_ERREXCEPT) is non-zero, then the invalid floating-point exception shall be raised. 🚨

the following sections are informative. (translation: cute bonus content, not requirements πŸ’–)

🌈 EXAMPLES 🌈

None. β€” not me showing up with zero examples. the audacity. πŸ™ˆ honestly? iconic.

πŸ’œ APPLICATION USAGE πŸ’œ

on error, the expressions (math_errhandling & MATH_ERRNO) and (math_errhandling & MATH_ERREXCEPT) are independent of each other, but at least one of them must be non-zero. like they're doing their own thing but you can't have both be zero, okay? that's the rule. 🫢

🧚 RATIONALE 🧚

so these functions differ from the llrint() functions in two very specific ways, and it's giving contrast:

  • the default rounding direction for the llround() functions rounds halfway cases away from zero
  • and they need not raise the inexact floating-point exception for non-integer arguments that round to within the range of the return type

that's it, that's the difference. πŸŽ€

⭐ FUTURE DIRECTIONS ⭐

None. β€” the future is bright and also empty. πŸ’…

πŸ‘‘ SEE ALSO πŸ‘‘

  • feclearexcept()
  • fetestexcept()
  • lround()
  • the Base Definitions volume of POSIX.1‐2017, Section 4.20, Treatment of Error Conditions for Mathematical Functions, <math.h>

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 .


okay that's the whole page bestie, tysm for reading 🫢 this was IEEE/The Open Group, 2017, and we were vibing in LLROUND(3POSIX) the entire time. go round some numbers, halfway cases away from zero, and stay iconic. mwah πŸ’…βœ¨