INET_ADDR(3POSIX)

πŸ¦‹ INET_ADDR(3POSIX) β€” the POSIX Programmer's Manual one πŸ’…

okay bestie, before we even get into it β€” this page lives in the POSIX Programmer's Manual πŸ“–, and there's a lil heads-up at the top you have to clock:

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 on Linux behavior), or the interface may not be implemented on Linux. 😭

so like. vibe check your platform first, k? 🫢


✨ PROLOG ✨

Yeah so that warning above is the prologue, no cap. It's the standard "this is POSIX, your Linux might be doing its own thing" disclaimer. Read the Linux man page too if you're on Linux, and if the interface isn't implemented there at all… well. πŸ™ˆ


🌸 NAME 🌸

inet_addr, inet_ntoa β€” IPv4 address manipulation, aka the glow-up from string to number and back again ✨


πŸŽ€ SYNOPSIS πŸŽ€

#include <arpa/inet.h>

in_addr_t inet_addr(const char *cp);
char *inet_ntoa(struct in_addr in);

look at her. two lil functions. iconic. πŸ‘‘


πŸ’– DESCRIPTION πŸ’–

okay so, two besties, two jobs:

  • inet_addr() takes the string that cp points at β€” written in the standard IPv4 dotted decimal notation β€” and converts it into an integer value that's suitable for use as an Internet address. string ➑️ number, slay.
  • inet_ntoa() does the opposite glow-up: it takes the Internet host address you hand it in in and turns it into a string in the Internet standard dot notation. number ➑️ string, periodt.
inet_ntoa() need not be thread-safe. 😭 not me getting overwritten by another thread. be careful out there.

All Internet addresses shall be returned in network order (bytes ordered from left to right). no funny business with the byte order, we're keeping it left-to-right, fr fr.


🌈 the forms, bestie (values in IPv4 dotted decimal notation) 🌈

Values specified using IPv4 dotted decimal notation take one of the following forms β€” and honestly the way they each mean something different is giving "why is networking like this":

  • a.b.c.d β€” when four parts are specified, each shall be interpreted as a byte of data and assigned, from left to right, to the four bytes of an Internet address. four parts, four bytes, one-to-one, so satisfying. πŸ’…
  • a.b.c β€” when a three-part address is specified, the last part shall be interpreted as a 16-bit quantity and placed in the rightmost two bytes of the network address. This makes the three-part address format convenient for specifying Class B network addresses as "128.net.host". cute shortcut, highkey useful. ✨
  • a.b β€” when a two-part address is supplied, the last part shall be interpreted as a 24-bit quantity and placed in the rightmost three bytes of the network address. This makes the two-part address format convenient for specifying Class A network addresses as "net.host". the compression is real. πŸ¦‹
  • a β€” when only one part is given, the value shall be stored directly in the network address without any byte rearrangement. no shuffling, no rearranging, just vibes. πŸ“

🧚 number bases, the part nobody expects 🧚

All numbers supplied as parts in IPv4 dotted decimal notation may be decimal, octal, or hexadecimal, as specified in the ISO C standard. So, exactly:

  • a leading 0x or 0X implies hexadecimal
  • otherwise, a leading '0' implies octal
  • otherwise, the number is interpreted as decimal

the way 010 is not ten… it's giving "why did you do this to me". 😭 but that's the rule, so.


πŸ”₯ RETURN VALUE πŸ”₯

  • Upon successful completion, inet_addr() shall return the Internet address. Otherwise, it shall return (in_addr_t)(-1). πŸ’€
  • inet_ntoa() shall return a pointer to the network address in Internet standard dot notation. pointer acquired, slay. ✨

⭐ ERRORS ⭐

No errors are defined. that's it, that's the section. πŸ’…

The following sections are informative. (aka: everything from here on is commentary, not gospel.)


πŸ“ EXAMPLES πŸ“

None. we are not being fed today bestie, sorry. 😭


πŸ‘‘ APPLICATION USAGE πŸ‘‘

The return value of inet_ntoa() may point to static data that may be overwritten by subsequent calls to inet_ntoa(). 🚨

so like, if you're holding onto that string and you call it again? your first string just got absolutely bodied. copy it if you need it, bestie. no cap.

πŸ’œ RATIONALE πŸ’œ

None. the committee said "no thoughts, head empty". πŸ™ˆ


🌸 FUTURE DIRECTIONS 🌸

None. she's staying exactly how she is. main character energy, no notes. ✨


πŸ¦‹ SEE ALSO πŸ¦‹

  • endhostent()
  • endnetent()
  • The Base Definitions volume of POSIX.1‐2017, <arpa_inet.h>

go read those too, iykyk πŸ“š


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 lil number came to you courtesy of IEEE/The Open Group, 2017 β€” mwah, drink water, check your byte order, and remember: inet_ntoa() is not thread-safe. bye bye πŸ’…πŸŒˆ