нет там такого поля 13 бит
есть поле 16 бит, и 3 бита в резерве....


дефайны наше все! Мы же работает на железном уровне, а не кнопки в бездушных программках рисуем%)



а как они кстати тип хоста узнают? все равно же какой то дефайн ест, или они при инициализации тест делают чтение - запись?

В случае нативной сборки (без кросс-компиляции) такие вещи можно узнать на этапе конфигурации (при выполнении скрипта configure). Например в autoconf есть макрос AC_C_BIGENDIAN, который при обнаружении big-endian хоста генерирует дефайн WORDS_BIGENDIAN.

В случае кросс-компиляции, наверное, для каждой target-архитектуры есть набор предопределенных дефайнов (если их не определяет сам компилятор). Можно, наверное, посмотреть, как это сделано, например, в glibc. Сам я специально этим не интересовался.

То есть да, какой-то дефайн наверняка все равно где-то есть, но главное, что это проблема библиотеки (и ее авторов), а не программиста, эту библиотеку использующего. Я как пользователь просто пишу в своем коде ntohl(), и могу не задумываться о том, как оно в коде библиотеки устроено, а могу сосредоточиться на своем собственном коде.

Конечно, если в библиотеке нет htonl/ntohl - тогда да, придется самому делать соответствующие дефайны и потом заботиться об их переопределении в случае смены целевой архитектуры...

Не правда Ваша, по ссылке пункт 3.1 "Fragment Offset"

моя правда
это 13 бит от общего служебного поля
Флаги + офсет, в сумме которое 16 бит.

надеюсь версию вы не считает 4 битным полем?

http://securos.org.ua/potencialno-uyazvimy...rotokole-tcpip/
Думаю самое правильное воспринимать заголовки
как 32 или 2 по 16, либо комбинация 2 по 8 и 16 бит.
Все более мелкие разделения должны входить в эти группы.

С этим спорить не буду, там более, что заголовки так и задумывались как 32 битные. Думаю, что к заголовкам вообще ни какие свапы применять нельзя, они, заголовки, должны изначально строится под конкретную архитектуру, пусть с дефайнами. А htonl/ntohl и пр... применимы только к данным.
По поводу данных. Кто мне помешает ради экономии памяти сделать поля 13 и 3 бита а 16 битном слове. Как в этом случае быть с htonl/ntohl?

ну как минимум вам мешают 2 вещи
1. это htonl/ntohl
2. это что нет стандартного типа данных 3 или 13 бит. А все остальные битовые поля компиляторо-зависимые. Проблем наживет, памяти не выиграете. Поставив поля 3 и 13 бит скорее всего будет 2 поля 8 + 16 бит, с вырезкой не пойми какой, ИМХО больше памяти пойдет чем на одно 16 битное поле.

Кстати как раз все кручение с биг и литл идет именно в заголовках. Так как в данных они лежат как послали. Компьютеры тоже Litle Endian, так что данные трогать не надо.

У вас есть некоторое непонимание происходящего, мне кажется. Если вы кладете 8 бит в 5 ячейку памяти, она так по езернету и пойдет, эти 8 бит так и останутся в 5 ячейе, никто их не переложит. Положите 16 бит, они так и будут там лежать, никто их не возьмет и не повернет.

Проблемы связаны с тем что если у вас есть 16 битное число 0xAABB в нулевой ячейке памяти, то в памяти оно ляжет в нулевую 0xBB, а в первую 0xAA, а в езернете наоборот. Соответственно когда по езернету к вам идет число 0xAABB, оно лежит в нулевой ячейке 0xAA, а в первой 0xBB, а процессор забирая его из памяти перевернет данные и вы получите 0xBBAA, потому их и надо свапануть, но это верно только если вы данные в память кладете и берете из нее словами.

Но никто вам не мешает класть данные руками по байтам, берем например число int Temp = 0xAABB. положите в 0 ячейку ((Temp >> 8)&0xFF),а в первую (Temp & 0xFF), и всех делов, сработает в любой системе хоть биг хоть литл.
И обратно
char *Data;
Temp = ((int)Data[0]<<8)|Data[1]); Опять же верно интерпретирует пришедшие по езернет данные в любой системе.