Why does POSIX contradict the ISO C standards [closed]

Question

See http://pubs.opengroup.org/onlinepubs/009696699/basedefs/sys/socket.h.html

(http://pubs.opengroup.org/onlinepubs/9699919799 is from Issue 7 - from 2013 and still the same!)

sockaddr_storage is meant to be cast to other structure types, but that contradicts the ANSI and ISO C standards aliasing rules as far as I can tell. (Objects may not be accessed through pointers to incompatible types, with the exception that anything can be accessed through the 3 char types and that the structure and its first member are interchangeable.)

I know that that practice of working with sockets existed long before C was standardised, but POSIX is supposed to conform to ISO C and actually it contradicts the standards in its manual. (Even in the newer versions of POSIX.)

Why did they make it like this in the first place? Why didn't they change it?

Maceio

Same issue with the dl_ family functions. – Elisavetgrad

I think this is basically "poor man's inheritance" in C. It's useful, lots of people use it, some standards even assume it, it works perfectly fine on all "conventional" architectures, but the ISO C Standard is painstakingly written to accommodate the unconventional architectures, too (even though those unconventional architectures, if any of them even exist at this point, will not be able to support e.g. Posix). – Hubert

@SteveSummit, I don't think you're right; this isn't about target architectures, this is about standards. GCC and Clang need -fno-strict-aliasing to correctly compile the code as intended by POSIX, AFAIK. – Maceio

@SteveSummit It's a bad excuse, actually. Standards are meant to be obeyed. – Osteoporosis

Posix dates from 1988, C was standardized in 1989. The battle between language implementers and language users has been raging ever since. – Aroid

@SteveSummit, I do not actually see a violation here, see my answer. – Kunzite

@HansPassant: And nobody will ever know for certain what the rules in C89 were intended to mean when they were written. If (as I believe) the rules were only meant to be applicable to things which are accessed both directly as objects and indirectly via pointers, that would allow the optimizations alluded to in the rationale without breaking much existing code. Hyper-modernists believe, however, the rules were intended to require programmers to jump through hoops to make use of existing constructs. I believe they're full of ??it, but can't prove what the C89 authors intended. – Archaism

Answer 1

The strict-aliasing rules in the standard constrain user code, not implementation code. Since the POSIX headers and libraries are part of the implementation, there is no actual conflict between the POSIX and the C standard.

In an open-source platform, and in particular in Linux where the C library and compiler are developed by different teams, this makes life difficult for implementors, but that is their concern, not yours. For example, the implementors could:

• refrain from exposing the potential conflict between the standards (that is, disable strict-aliasing optimizations);
• admit that their implementation is not POSIX compliant (and note that, for example, there are no POSIX-certified Linux distributions);
• provide facilities to ensure that the potentially conflicting facilities do not actually conflict. From the point of view of the C standard, this would be an extension.

This last option is how the gcc and glibc teams are working to resolve the sockaddr issue; see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71255

Haunting

Note that there are distributions that are certified to be POSIX-compliant ; see here : unix.stackexchange.com/questions/293396/… The reason for which those distributions are rare is that there is a significant monetary cost to certification which is prohibitive to most Linux distributions – Smoulder

Answer 2

As a matter of fact, I do not think there is a violation of strict aliasing rule here. Yes, you cast it to a different type when you call a function, but who said it has to be accessed through pointer of this type?

Protocol implementations know the proper type of the structure, so when they access the structure, they convert it back to the proper type. Conversion here is only used for passing pointer from one routine to another, but converted type is not used to access the data.

Kunzite

Protocol implementations know the proper type of the structure --- maybe they do, maybe not. If they do, why sa_family is a part of struct sockaddr? – Wisteria