feat(net): implement the eNet socket API on POSIX sockets

[srpatcha]

ADR-014 point 3: "On the Compute profile, where a host OS is present, the same API maps to POSIX sockets." This is that mapping.

Before this, every socket function in eNet was a stub:

int eos_net_connect(eos_socket_t sock, const eos_net_addr_t *addr)
{
    (void)sock; (void)addr;
    return -1;
}

eos_net_socket() returned an incrementing integer naming nothing. Anything built on eNet could not be exercised on any target — including the host, which is where EoSim runs and where the org's own ecosystem gate would test it.

[PASS] net tcp round trip
[PASS] net resolve localhost
[PASS] net connect to a closed port fails

The fd is the handle

eos_socket_t is an int, EOS_SOCKET_INVALID is -1, and that is exactly what socket(2) returns on failure. No descriptor table to keep in step, and no way for the two to drift.

Three things not obvious from the API shape

• eos_net_addr_t documents ip as network byte order, so it's copied into sin_addr rather than passed through htonl — which would swap it twice.
• send uses MSG_NOSIGNAL. Writing to a peer that has gone away raises SIGPIPE by default, which kills the process instead of returning an error the caller can act on.
• A zero timeout means "block forever" to SO_RCVTIMEO — the opposite of what a caller passing 0 expects. The option is only set when non-zero. A timed-out recv returns 0, not -1: no bytes arrived, nothing failed.

The stubs stay

Behind #ifndef EOS_NET_POSIX, not deleted. On a target with no IP stack, failing is the honest answer — and that is the Planned state ADR-014 records for Nano and Edge until lwIP lands.

A gating trap worth knowing about

Gated on CMAKE_CROSSCOMPILING alone, deliberately not on the EOS_PLATFORM STREQUAL "linux" OR NOT CMAKE_CROSSCOMPILING form used a few lines above for hal_linux.c.

EOS_PLATFORM defaults to "linux" and a cross toolchain file does not change it, so that condition is true even for a Cortex-M build. I used it first and the ARM build failed on <netdb.h>.

hal_linux.c survives the same condition only because it uses portable headers — but it is being compiled into the Cortex-M build today. Worth a separate look; I've left it alone.

Scope

The socket layer. ADR-014 point 5 keeps MQTT, CoAP and HTTP out as separate adoption decisions on top of a working IP stack; they remain stubs. This does not make eNet Implemented — lwIP is still the decision for the profiles with no host OS to borrow sockets from.

Verification

host ctest	28/28; test_net 16 → 19 cases
bare-metal Cortex-M	net.c compiles with EOS_ENABLE_NET=1, defines eos_net_connect exactly once — as does the host build
ARM cross-build	clean, 0 errors

🤖 Generated with Claude Code