The ifconfig tool has long had the ability to suppress implicit bring up
by adding an - suffix to the alias name.  Document this in the man page.

URL: https://bugs.gentoo.org/568446Reported-by: Joakim Tjernlund <joakim.tjernlund@infinera.com>

We use scanf %64[...] to get local addresses, but then we store the result
into a char[64] buffer.  Since scanf always writes a terminating NUL, we
overflow the buffer by a single byte.  Use a buffer of 128 bytes to match
the style of other funcs in this file.
Reported-by: Maxim Ostapenko <m.ostapenko@partner.samsung.com>

This changes the hostname behavior to match other systems and its own
documentation.  Namely, that -s just parses the result of the active
gethostname() and does not attempt any network/DNS traffic.  Other
distros like Fedora/RedHat and Debian/Ubuntu have also changed their
behavior in this regard.

URL: https://bugzilla.redhat.com/319981
URL: https://bugzilla.redhat.com/531702
URL: https://bugs.debian.org/552482
URL: https://bugs.gentoo.org/515836

After the typo fixes, some of the translations were duplicated leading
to errors during message generation.

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).