История изменений
Исправление firkax, (текущая версия) :
От 128:
1) sizeof(struct sockaddr_in6)>sizeof(struct sockaddr)
При этом предполагалось что 16-байтного абстрактного struct sockaddr должно хватить на любые адреса, кроме unix-сокетов, кто-то мог выделять его статически и класть в него адрес уже конкретного класса (а в sockaddr_in есть паддинг для приведения его размера к эталонному), с добавлением 28-байтного sockaddr_in6 это приводит к битью памяти и необходимости пересмотра части алгоритмов.
2) 128 просто слишком сложно. 4 числа запоминаются элементарно, 8 чисел - чуть сложнее, но тоже норм. 16 чисел - ужасно, а ещё и с придумыванием какого-то необычного формата их текстового представления - и того хуже. Теорию про «можно же пропустить нули в середине» впаривать не надо. Этот фокус ничего не упрощает, а наоборот усложняет: у тебя записано не пойми что ::1 и тебе надо вспоминать как оно преобразуется в нормальный побитовый формат.
При этом то, что в 128 битах не было абсолютно никакой нужды, подтверждается сразу же чтением рекомендаций по распределению адресов от тех же авторов, где они делегирование чего-то длиннее 64 битов вообще не рассматривают (а обычно рассматривают короче), и младшие 64 бита адреса предлагают заполнять всяким мусором.
Исправление firkax, :
От 128:
1) sizeof(struct sockaddr_in6)>sizeof(struct sockaddr)
При этом предполагалось что 16-байтного абстрактного struct sockaddr должно хватить на любые адреса, кроме unix-сокетов, кто-то мог выделять его статически и класть в него адрес уже конкретного класса (а в sockaddr_in есть паддинг для приведения его размера к эталонному), с добавлением 28-байтного sockaddr_in6 это приводит к битью памяти и необходимости пересмотра части алгоритмов.
2) 128 просто слишком сложно. 4 числа запоминаются элементарно, 8 чисел - чуть сложнее, но тоже норм. 16 чисел - ужасно, а ещё и с придумыванием какого-то необычного формата их текстового представления - и того хуже. Теорию про «можно же пропустить нули в середине» впаривать не надо. Этот фокус ничего не упрощает, а наоборот усложняет: у тебя записано не пойми что ::1 и тебе надо вспоминать как оно преобразуется в нормальный побитовый формат.
При этом то, что в 128 битах не было абсолютно никакой нужды, подтверждается сразу же чтением рекомендаций по распределению адресов от тех же авторов, где они делегирование чего-то длиннее 64 битов вообще не рассматривают (а обычно рассматривают короче), и младшие 64 бита адреса предлагают заполнить всяким мусором.
Исправление firkax, :
От 128:
1) sizeof(struct sockaddr_in6)>sizeof(struct sockaddr)
При этом предполагалось что 16-байтного абстрактного struct sockaddr должно хватить на любые адреса, кроме unix-сокетов, кто-то мог выделять его статически и класть в него адрес уже конкретного класса, с добавлением 28-байтного sockaddr_in6 это приводит к битью памяти и необходимости пересмотра части алгоритмов.
2) 128 просто слишком сложно. 4 числа запоминаются элементарно, 8 чисел - чуть сложнее, но тоже норм. 16 чисел - ужасно, а ещё и с придумыванием какого-то необычного формата их текстового представления - и того хуже. Теорию про «можно же пропустить нули в середине» впаривать не надо. Этот фокус ничего не упрощает, а наоборот усложняет: у тебя записано не пойми что ::1 и тебе надо вспоминать как оно преобразуется в нормальный побитовый формат.
При этом то, что в 128 битах не было абсолютно никакой нужды, подтверждается сразу же чтением рекомендаций по распределению адресов от тех же авторов, где они делегирование чего-то длиннее 64 битов вообще не рассматривают (а обычно рассматривают короче), и младшие 64 бита адреса предлагают заполнить всяким мусором.
Исходная версия firkax, :
От 128:
1) sizeof(struct sockaddr_in6)>sizeof(struct sockaddr)
При этом предполагалось что 16-байтного sockaddr_in должно хватить на любые адреса, кроме unix-сокетов, кто-то мог выделять его статически и класть в него адрес уже конкретного класса, с добавлением 28-байтного sockaddr_in6 это приводит к битью памяти и необходимости пересмотра части алгоритмов.
2) 128 просто слишком сложно. 4 числа запоминаются элементарно, 8 чисел - чуть сложнее, но тоже норм. 16 чисел - ужасно, а ещё и с придумыванием какого-то необычного формата их текстового представления - и того хуже. Теорию про «можно же пропустить нули в середине» впаривать не надо. Этот фокус ничего не упрощает, а наоборот усложняет: у тебя записано не пойми что ::1 и тебе надо вспоминать как оно преобразуется в нормальный побитовый формат.
При этом то, что в 128 битах не было абсолютно никакой нужды, подтверждается сразу же чтением рекомендаций по распределению адресов от тех же авторов, где они делегирование чего-то длиннее 64 битов вообще не рассматривают (а обычно рассматривают короче), и младшие 64 бита адреса предлагают заполнить всяким мусором.