Not all sockaddr structs have the same alignment.  Instead, it depends
on the fields contained in it.  The way net-tools has written things
though, it accepts sockaddr* everywhere which has 16bit alignment, even
though it will cast it to other sockaddr types that have higher alignment.
For example, `route` can crash on alpha because it declares sockaddr on
the stack, but then casts it up to sockaddr_in6 (which has 32bits).

It's also bad storage wise as we might try to cast the sockaddr to a type
that is larger than sockaddr which means clobbering the stack.

Instead, lets rewrite all the APIs to take a sockaddr_storage.  This is
guaranteed to have both the maximum alignment and size requirements for
all other sockaddr types.  Now we can safely cast that pointer to any
other sockaddr type and not worry about it.  It also has the nice effect
of deleting a lot of casts in a lot of places when we only need the type
of family.

The vast majority of changes here are mechanical.  There are a few places
where we have to memcpy between a dedicated sockaddr_storage and a smaller
struct because we're using an external embedded type (like arpreq).

URL: https://bugs.gentoo.org/558436

Rather than use different sockaddr base types for storage, always
start with sockaddr_storage on the stack and set up pointers to
more limited versions to that.  This way we always get the correct
alignment and storage when we pass it down to lower layers.

This is really just a set up for a follow up change to convert the
codebase entirely to sockaddr_storage.  This is just a fairly self
contained change.

Signed-off-by: Jiri Popelka <jpopelka@redhat.com>

This way we can support any length line w/out hardcoded buffer limits.

Move the strlen calculation outside the loop to avoid recalculating it
every time.

In the output of netstat --ipx, the network and port numbers are byteswapped.
For instance:

Proto Recv-Q Send-Q Local Address              Foreign Address            State
IPX        0      0 000A6F83:2E40              04036F83:000000000001:5104 ESTAB

The local network number is actually 836F0A00, and the NetWare server reports
my socket number as 402E.  Similarly, the server's address is
836F0304:000000000001, and the standard NCP port is 0415.

URL: https://bugzilla.redhat.com/show_bug.cgi?id=46434Reported-by: Ben Harris <bjh21@cam.ac.uk>

The parsing logic doesn't handle IPv6 addresses.
Clean it all up.

Rather than do the sorting at runtime, run the tables through `sort`.
This lets us constify them and speed up runtime slightly.

Mark all the read-only strings in this file as const.

The vast majority of these aren't used outside of this file, so mark
them all static accordingly.

Some of the globs might expand into files that start with a dash, so
pass -- everywhere to keep problems from showing up.  Some call sites
don't actually need this, but better to be consistent.

There's no need to cast the char* to a struct in6_addr*, so delete
that logic.

Switch the hardcoded 80 limit to the INET6_ADDRSTRLEN constant.

Make sure the buffer we pass into inet_ntop is always NUL terminated.

This is only used in this file, so localize it.

This might end up violating alignment requirements, so memcpy the
variable through a short variable instead.  For most systems, this
will optimize into the same code anyways, and for the rest, we need
to do it this way to avoid unaligned accesses crashing.

URL: https://bugs.gentoo.org/558436

This avoids casting from a char* pointer to a struct in_addr* pointer
which have different alignment requirements, and moves away from the
deprecated inet_ntoa function.

URL: https://bugs.gentoo.org/558436

The former is the standard name now while the latter is the old one.

The code assumes that sizeof(sin_addr.s_addr) == sizeof(long) == 4 which
fails badly on 64bit systems -- we end up reading 4 extra bytes into the
storage.  Instead, load things indirectly via uint32_t variables since
these are IPv4 addresses.

Use inet_ntop everywhere so that we only have one code path between IPv4
and IPv6.  This also fixes some alignment warnings (due to gethostname
returning char* pointers which we then cast up to in_addr structs).

URL: https://bugs.gentoo.org/558436

Most callers never modify this structure, so constify it everywhere.

Most callers never modify this structure, so constify it everywhere.

These strings are static data set in sub-modules and never modified.

This string is never modified, so constify it.

These are only used internally to initialize themselves, so mark them
static.

These functions are almost entirely the same, so re-use the existing
function rather than duplicate the body.

Wrong conditional includes intended for support of libc5 and glibc
2.0 prevented compilation under systems with alternative libcs,
such as musl. For simplicity, remove these includes necessary for
libc5 and glibc 2.0.

Currently uses sysconf(_SC_TC_CLK) to be more portable.

Make sure we use 64-bit filesystem functions everywhere.  This applies not
only to being able to read large files (which generally doesn't apply to
us), but also being able to simply stat them (as they might be using large
inodes).

No L2CAP or RFCOMM stats doesn't imply no support for Bluetooth; merely a
protocol missing.

An address type field was added, messing up our l2cap status parsing.

When an interface has transferred exbibytes
(> 0.8 EiB, i.e. > 819 PiB) of traffic,
the short display is rounded incorrectly.

For example:
bytes 2154408931384050514 (275.0 PiB)
while correct is (1913.4 PiB)

This happens because we times the rx/tx bytes values by 10,
then calculate the short version from that result:

lib/interface.c:ife_print_long()

tx = ptr->stats.tx_bytes;
short_tx = tx * 10;
if (tx > 1125899906842624ull) {
  short_tx /= 1125899906842624ull;
  Text = "PiB";
}

But multiplying anything more than 819 PiB by 10 overflows a ull
which is a uint64_t (max value of 9223372036854775807).

We'll never get accuracy over 8192 PiB (2^64) when using ull,
but we can at least correctly handle values between 819 - 8192 PiB.

The reason is that debugfs is accessible only by root user:
_PATH_SYS_BLUETOOTH_L2CAP  /sys/kernel/debug/bluetooth/l2cap
_PATH_SYS_BLUETOOTH_RFCOMM /sys/kernel/debug/bluetooth/rfcom

URL: https://www.kernel.org/doc/Documentation/filesystems/debugfs.txt
URL: https://bugzilla.redhat.com/show_bug.cgi?id=1162284

This reverts commit 343192d1.

This fix from RedHat was actually a fix for one of their custom patches.
Applying it to mainline breaks interface stats.