Fixed AF_INET6 number to match C-library defines

[danielinux]

Contribution description

AF_INET and AF_INET6 have POSIX-wide accepted numbers across different systems (4 and 10 respectively).

Violating this assignment may cause library calls related, e.g. to IP address handling, to fail.

This patch keeps the enum type, but assigns the right numbers to AF_INET and AF_INET6 so that libraries are not confused by the label mismatch.

Testing procedure

Simply calling inet_pton() with the wrong address family on native triggers the problem.
inet_pton() returns '0' (error) and sets errno to 97 (EAFNOSUPPORT).

See simple test to reproduce:
https://github.com/danielinux/RIOT-OS-posix-tcp-socket-example

Issues/PRs references

This defect has been discovered while working on PR #10308 - but it's not related to TLS sockets.

See also: #12130 which can be blocking for the test.

cc: @miri64

[benpicco]

Let's see if CI is complaining about the removal of AF_NUMOF / AF_MAX

[benpicco]

Looks like oonf_api likes to use it to define some additional address families

enum {
    AF_MAC48 = AF_MAX + 1,
    AF_EUI64 = AF_MAX + 2,
};

[danielinux]

Force-pushed again, re-introducing AF_NUMOF + AF_MAX, changed the comment since it does not reflect the number of (known) AF on the system

[miri64]

Do you have some reference, that this is POSIX defined? AFAIK the actual values are not defined, but only the names.

[cladmi]

Unfortunately there are no "common values" for AF_INET6. Posix is only an API and not an ABI or fixes any values.

I did the same mistake and had to revert my change in #8940

Quote from that PR:

So even right now, if we look at the values of AF_INET6, they are not compatible:

* RIOT: 4
* Linux: 10
* MAC: 30

[cladmi]

The issue is that a module is not supposed to directly call the system posix function (except in native specific modules) but only a RIOT wrapper.

If the function is missing, it must be added to RIOT posix attempted compatibility layer.

[danielinux]

I don't think that this is a standard, just a widely agreed practice to keep these numbers aligned.
LWIP itself has these number defined correctly in include/lwip/sockets.h.

[miri64]

I don't think that this is a standard, just a widely agreed practice to keep these numbers aligned.

Doesn't @cladmi's comment contradict this with regards to Linux vs. Mac?

LWIP itself has these number defined correctly in include/lwip/sockets.h.

What is "correct" in this light?

[danielinux]

What is "correct" in this light?

Since we are using posix system calls with lwIP, I would expect that those numbers are aligned in the source when module_lwip and module_posix_sockets are selected together.

Even if LWIP_SOCKET is never used, it's still confusing to have the same symbol showing up twice in the source code search with two conflicting values.

I was not aware of MacOS using a different value.

[miri64]

Since we are using posix system calls with lwIP, I would expect that those numbers are aligned in the source when module_lwip and module_posix_sockets are selected together.

Agreed, but that should rather then happen via CPP/buildsystem magic that the right value is always used, than by fixing the values of RIOT to those of one particular external package (be they "more correct" or not), just because they happen to be the same as on Linux. A different external network stack package might have a different value yet again.

I was not aware of MacOS using a different value.

FreeBSD uses yet another value so I don't think there is any convergence of the values.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.