> sock = inet_connect(SOCK_STREAM, “google.com”, 443, NULL, &err);

You just added a DNS lookup to connect(2).

Also, you linked socket creation to all of this. This would make it hard to do an asynchronous version. Today you can create a socket and do a non-blocking connect(2) (after doing your asynchronous DNS lookup)

Lastly, I think if you tasked someone with creating that API, they would probably use the old APIs to build it ...

I think plan9 API is the sanest one https://9fans.github.io/plan9port/man/man3/dial.html

This is one of the most unfortunate cases of UB in C. It's necessary because C largely doesn't forbid pointer aliasing (accessing an object using multiple, distinct pointers). But the compiler needs to have some idea of when pointers might alias; otherwise, it's forced to generate extremely inefficient code that redundantly loads pointers over and over again just in case the value changed unexpectedly.

Within the body of a single function, the compiler can see where addresses came from and figure out what pointers may or may not alias. But when pointers are passed in as function parameters, the compiler has no idea. Thus, the C standard allows compilers to assume that pointers to different types never refer to the same object; an assumption that's true for almost all code anyone would want to write. But this adds surprising undefined behavior to some things you might try, like casting between layout-compatible structs, or the fast inverse square root trick from Quake. (Casting a pointer to a different type can still be tricky to get right even if it wasn't UB though. Alignment requirements are another footgun: for example, it's not legal to cast a uint8_t pointer to a uint16_t pointer unless you're sure its address is even.)

The blessed-by-the-standard way to do type punning is to either use a union or a memcpy, not a pointer cast.

For comparison, Rust prohibits mutable pointer aliasing for safe reference types, so the compiler knows when references may or may not alias. (Raw pointers are assumed to always be aliasable unless the compiler can prove that they're unique, e.g. by being derived from a safe reference). This leads to more efficient codegen in many cases, but it also means that type punning through pointer casting is fully legal in unsafe code (provided validity and alignment requirements are met), since the compiler does not need the type information to figure out aliasing.

As far as standard ISO C goes, nothing. That's just how UB can work in theory, though in practice compiler (ab)use of UB is somewhat more indirect (optimizing under the assumption that UB is not present in the program, rather than observing UB and making decisions based on that).

Beyond that, I believe Linux and other kernels technically use a slight variant of C by taking advantage of compiler extensions/flags to better fit their use cases. For example, Linux compiles (compiled?) with -fno-strict-aliasing and -fwrapv and uses a GCC extensions that allows type punning via unions [0], so that they can compile what the standard calls "incorrect" C code without worry.

I'm not sure whether recent versions of C have changed their stance on this particular UB, but since it'll probably be a while until they're adopted (if ever) kernels will be making do with their workarounds for a while longer.

[0]: https://lkml.org/lkml/2018/6/5/769

It's not UB if the "common initial sequence" exemption applies as it does here.

Nothing in the language, though the permissions mechanism of the system may disallow it. Unless the compiler is running with root permissions.

C is not a safe language. The more abrasive among fans of the language would say "skill issue" and "git gud" if you want to avoid footguns.

What kind of mechanism is there in place to prevent any compiler from just replacing your main() function with formatting /dev/sda?

That's nothing to do with the language, that's always on the compiler. Nothing stops the compiler from taking even correctly-specified code and doing whatever it wants.

I'd think this is an extremely common pattern anyway (with the declared array length been 1, or even some other "minimal storage value"), and likely struct sockaddr's use of it is the cherry on the top.

Yeah it's interesting that a (relatively) small quirk in the Linux source has the "political leverage" to impact the whole C ecosystem.

I suppose C was made for Unix at Bell Labs and GCC is also inextricably tied, you could say that C is first and foremost the language of Linux, fair enough.

You don't need the Ex thing with socket addresses because they have a run-time type field: sa_family.

A function that takes a sockaddr * can dereference it to get at that field, and then know exactly which address type it's dealing with.

You can introduce new APIs and new types to resolve the "is it flexible, or is it 14 chars"; that's more or less one of the explored approaches in the article.

It won't make existing uses any clearer or safer though, requiring rewrites to take advantage of them.

If the goal here is to reduce attack surface or bug-prone code in the kernel, leaving the non-ex variants around unchanged wouldn't help much with that.

Some platforms have a field called sa_len.

That's essentially what it is.

You can determine the size by looking at sa_family.

Some platforms also have an sa_len field.

It's still unsafe if you allocate for the "base" type of struct sockaddr then try to use it for something larger, but that generally is not done. People usually allocate for the exact type they want, and only pointers to the structure are passed around, often opaquely.