Согласен.

Вот именно. и из этих 80 бит под мантиссу отводится 64 . В long double
(Соответственно в double из 64 бит под мантиссу отводится 53)

Напомню, откуда спор возник. P@Sol заметил, что с числами, мантисса которых вылезает за пределы 11 бит, творится что-то неладное. Вы посоветовали ему реализовать 80 бит. А я лишь заметил, что с такой точностю, плавучку никто не реализует.
Есть, конечно где-то в IEEE четырехкратная точность в 128 бит, из которых 112 отданы под мантиссу, но физически я её ни разу не видел. А чтоб 80 кто-то под мантиссу отдал, не видел и на бумаге.

В long double в 32-битной архитектуре под число отводится 80 бит, двумя лишними байтами в Linux выравнивают число. В Windows скорее всего тоже так, но реализации доступных мне компиляторов возвращают фактическое число 80 бит. 64 бита отводится обычно просто под double.

long double в Linux занимает 12 байт. Согласен.
Но Вы уверены, что под мантиссу в нем отводится больше 64 бит?

long double имею ввиду (в Linux он вообще 12 байт занимает, вместо 10 в Windows).

80? Странный выбор размера мантиссы. Она даже у long double (который занимает 10 байт)лишь 64 бита. Остальные 16 бит отданы на хранение знака и характеристики.

Нет, 11 бит маловато, в идеале нужна поддержка 80 бит.

Согласен, не дело, поправим в ближайшее время.

Вы наверное 1000000000 как число храните, а не как строку.
Числа больше 10 цифр в формат int просто напросто не помещаются. Если цифры десятичные. :))

после этого числа (больше 1023 в десятичной) скрипт перевода чисел из двоичной в десятичную перестает работать правильно, 10000000000(2) - уже не работает