Почему POSIX противоречит стандартам ISO C [закрыто]

Увидетьhttp://pubs.opengroup.org/onlinepubs/009696699/basedefs/sys/socket.h.html

(http://pubs.opengroup.org/onlinepubs/9699919799 это из номера 7 - с 2013 года и все тот же!)

sockaddr_storage предназначен для приведения к другим типам структур, но, насколько я могу судить, это противоречит правилам наложения стандартов ANSI и ISO C. (К объектам нельзя обращаться через указатели на несовместимые типы, за исключением того, что к чему-либо можно получить доступ через 3 типа символов и что структура и ее первый член являются взаимозаменяемыми.)

Я знаю, что такая практика работы с сокетами существовала задолго до стандартизации C, но предполагается, что POSIX соответствует ISO C и фактически противоречит стандартам, изложенным в его руководстве. (Даже в более новых версиях POSIX.)

Почему они сделали это так во-первых? Почему они не изменили это?

 Karoly Horvath06 июн. 2016 г., 17:20
Та же проблема сdl_ семейные функции.
 user237314506 июн. 2016 г., 17:33
@ SteveSummit, я не думаю, что ты прав; речь идет не о целевых архитектурах, а о стандартах. GCC и Clang необходимо -fno-strict-aliasing для правильной компиляции кода, как это предусмотрено POSIX, AFAIK.
 Steve Summit06 июн. 2016 г., 17:30
Я думаю, что это в основном «наследство бедняков» в Си. Это полезно, многие используют его, некоторые стандарты даже предполагают, что оно прекрасно работает на всех «обычных» архитектурах, но стандарт ISO C кропотливо написан для учета тоже нетрадиционные архитектуры (даже если эти нетрадиционные архитектуры, если они вообще существуют на данный момент, не смогут поддерживать, например, Posix).
 Eugene Sh.06 июн. 2016 г., 17:33
@ SteveSummit Это плохое оправдание, на самом деле. Стандарты предназначены для соблюдения.
 Hans Passant06 июн. 2016 г., 17:40
Posix датируется 1988 годом, C был стандартизирован в 1989 году. С тех пор продолжается ожесточенная битва между разработчиками и пользователями языков.
 SergeyA06 июн. 2016 г., 17:50
@ SteveSummit, я на самом деле не вижу здесь нарушения, см. Мой ответ.
 supercat06 июн. 2016 г., 20:16
@HansPassant: И никто никогда не узнает наверняка, что означали правила в C89, когда они были написаны. Если бы (как я полагаю) правила предназначались только для того, чтобы быть применимыми к вещам, доступ к которым осуществляется как напрямую, так и косвенно через указатели, это позволило бы выполнить оптимизацию, на которую ссылаются в обосновании, без нарушения существующего кода. Однако гипермодернисты считают, что правила должны были требовать, чтобы программисты перепрыгивали через обручи, чтобы использовать существующие конструкции. Я полагаю, что они полны этого, но не могут доказать, что авторы C89 намеревались.

Ответы на вопрос(2)

код, а не код реализации. Поскольку заголовки и библиотеки POSIX являются частью реализации, фактического конфликта между POSIX и стандартом C.

В платформе с открытым исходным кодом, в частности в Linux, где библиотека и компилятор C разрабатываются разными командами, это усложняет жизнь разработчикам, но это их забота, а не ваша. Например, разработчики могли бы:

воздерживаться от разоблачения потенциального конфликта между стандартами (то есть отключить оптимизацию со строгим псевдонимом);признать, что их реализация не совместима с POSIX (и обратите внимание, что, например, не существует POSIX-сертифицированных дистрибутивов Linux);обеспечить возможности для того, чтобы потенциально конфликтующие объекты фактически не конфликтовали. С точки зрения стандарта C, это будет расширение.

Этот последний вариант показывает, как команды gcc и glibc работают над решением проблемы sockaddr; увидетьhttps://gcc.gnu.org/bugzilla/show_bug.cgi?id=71255

я не думаю, что здесь есть нарушение строгого правила псевдонимов. Да, вы приводите его к другому типу при вызове функции, но кто сказал, что к нему нужно обращаться через указатель этого типа?

Реализации протокола знают правильный тип структуры, поэтому, когда они получают доступ к структуре, они преобразуют ее обратно в правильный тип. Преобразование здесь используется только для передачи указателя из одной подпрограммы в другую, но преобразованный тип не используется для доступа к данным.

 n.m.06 июн. 2016 г., 18:15
Protocol implementations know the proper type of the structure --- может быть, а может и нет. Если они делают, почемуsa_family является частьюstruct sockaddr?

Ваш ответ на вопрос