Несоответствие реализации в Linux стандарту

posix не нужен

код в линуксе - стандарт де факто /thread

Из bits/socket.h

struct cmsghdr
{
    size_t cmsg_len;		/* Length of data in cmsg_data plus length
				   of cmsghdr structure.
				   !! The type should be socklen_t but the
				   definition of the kernel is incompatible
				   with this.  */
...

Думаю, комментарии излишни :))

Из man 3 cmsg:

struct cmsghdr {
    socklen_t cmsg_len;    /* data byte count, including header */
    int       cmsg_level;  /* originating protocol */
    int       cmsg_type;   /* protocol-specific type */
    /* followed by unsigned char cmsg_data[]; */
};

Думаю, комментарии излишни.

код в линуксе - стандарт де факто /thread

Из-за таких как ты мы до сих пор не можем избавиться от Microsoft Office и еле еле избавились от Internet Explorer. Стандарты де-факто, хрен ли.

The type should be socklen_t but the definition of the kernel is incompatible with this

С ЛОРа не уходят!

Я об этом написал в оригинальном посте.

Так если

в ядре лялекса и glibc

размер переменной на самом деле больше, чем надо, как ты умудрялся передавать в ней неверное значение? Или просто поля в сформированной из биндинга структуре корраптились из-за (в итоге) неверных смещений?

просто поля в сформированной из биндинга структуре корраптились из-за (в итоге) неверных смещений?

Вот это. Когда я засунул printk в ядро в нужные места, выяснилось, что в верхней половине переменной полная хрень.

таскать костыль в коде, получается. Выпиливание из ядра это поломка ABI, и комментарий в хедере, думаю, шрам от чьих-то безуспешных попыток это продвинуть.

Где может выстрелить костыльность этого метода? На ум приходит только портирование на не-linux

Вернее, остальные поля были в порядке, так как hsc2hs генерировал корректные смещения. Только в cmsg_len в верхней половине была полная хрень, т.к. poke записывал только 32 бита. При этом всё strace показывал корректное значение (верхние 32 бита игнорировались).

ЛОЛШТО? Даже для тех, кому ляликс нафиг не вперся?

ТС, а в чём костыль? Прикрути к биндингу свой портабельный тип и пользуйся им. Вполне нормально

В лишнем ifdef. В хаскелл функция poke для 32-битного типа заполнит только 32 бита (К.О.), остальные 32 бита поля останутся нетронутыми. Внутри и так используется портабельный тип, но при вызове системных функций приходится конвертировать.

Иначе никак, походу. Не такая уж редкая ситуация

Иначе никак, походу. Не такая уж редкая ситуация

Ну почему же, можно слить glibc и linux kernel в одно дерево исходных кодов, и объявить что между релизами бинарная совместимость не гарантируется. В OpenBSD, например, так и сделано, и вроде всё ок. Проприетарный софт не работает, но проблемы негров шериф^WТео вроде не особо волнуют.

объявить что между релизами бинарная совместимость не гарантируется

https://lkml.org/lkml/2012/3/8/495

https://lkml.org/lkml/2012/3/8/495

Кого волнует мнение какого-то жирного финна? Его наверняка жена заставила это написать.

слить glibc и linux kernel в одно дерево исходных кодов

Когда поставляют голое ядро, а не ось целиком, выходит одно недоразумение, это же очевидно.

объявить что между релизами бинарная совместимость не гарантируется

Ога, я между 3.4 и 3.6 драгонфлаем все пакеты пересобирал

Когда поставляют голое ядро, а не ось целиком, выходит одно недоразумение, это же очевидно.

Никто ж не запрещает сборку отдельно ядра или отдельно libc. Зато, если у них будет общий код - хотя бы те же хидеры с объявлениями структур и констант, подобные этому баги будет исправить куда проще.

Ога, я между 3.4 и 3.6 драгонфлаем все пакеты пересобирал

Пересобрал? Пересобрал. Работает? Работает. Не вижу проблемы (у меня просто Gentoo).

Пересобрал? Пересобрал. Работает? Работает. Не вижу проблемы (у меня просто Gentoo).

Долговато. Так что жена Торвыльдса немного права. Но совсем немного

http://git.musl-libc.org/cgit/musl/tree/arch/x86_64/bits/socket.h

Вот как по-хорошему это можно было бы решить.