[dwattttt]

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.

[kazinator]

The array should not be touched so the question is moot. The struck sockaddr type should only be used for pointers, which are cast to the correct type according to their family before they're are dereferenced, with the exception that the sa_family member can be accessed through the sockaddr base.

For defining or allocating an object that can hold any address, sa_storage should be used, mentioned in the article.

[dwattttt]

I imagine the problem they're trying to address is ensuring that everyone _does_ only use correctly cast pointers; as defined, it's legal to use that 14 char array, it's just that it's never what you're meant to do.

[kazinator]

In my opinion, the array should be marked obsolescent, and removed (not necessarily physically, but the name gone from the member namespace). The 14 bytes is not enough for it to be define storage for all types, which is why sockaddr_storage is there. It cannot meaningfully access anything. Implementations could rename it to some __sa_data or whatever name so that the size of the structure doesn't change, if that is important to them.