= Сообщение: 81 из 1924 =========================================== RU.BINKD = От : Pavel Gulchouck 2:463/68 05 Nov 13 09:12:02 Кому : Roman Trunov 05 Nov 13 09:12:02 Тема : То ли лыжи не едут... FGHI : area://RU.BINKD?msgid=2:463/68+5278a0df На : area://RU.BINKD?msgid=2:5022/2+52790f84 = Кодировка сообщения определена как: CP866 ================================== Ответ: area://RU.BINKD?msgid=2:5022/2+52793e1d ============================================================================== Hi Roman!
05 Nov 13, Roman Trunov ==> Pavel Gulchouck:
PG>> Под linux и freebsd 4G-файлы давно и уверенно передаются/принимаются.
RT> Hе-а. Там минимум в двух местах в protocol.c простой atol был. Видать, никто в эту ветку кода пока не попадал. А кто RT> попадал - ничего не понял :)
Мда, действительно. :( Значит, тестировалось на 64-битной системе. :)
PG>> Кажется, mingw-сборка тоже поддерживает (хотя в этом не уверен).
RT> Теоретически шансы есть, там же инклуды ближе к линуксовым и _FILE_OFFSET_BITS может сразу заработать.
RT> А вот Билли опять подложил свинью. Во всех MSVC по крайней мере до 2010 включительно off_t есть, но он ВСЕГДА RT> 32-битный. Пришлось заводить собственный boff_t и определять соответственно.
А есть ли там fseeko() и ftello() или что-то вместо них?
RT> В общем, некоторый прогресс у меня есть, под MSVC 10.0/2010 оно уже собирается правильно, сейчас нужно еще доделать RT> сборку под более ранними версиями MSVC (собранное 10.0 не работает под Win2K как минимум). И еще я бы хотел перетрясти RT> использование системных #include (stdio.h и т.п.) в основном коде. По моему сформировавшемуся с годами мнению - в RT> подобных кросс-платформенных проектах там их быть не должно. Все модули (хотя бы из "корня" проекта, про RT> платформо-зависимые костыли пока можно не говорить) должны начинаться с #include "sys.h", а уже в нем должен RT> инклюдиться джентельменский набор системных хеадеров - с учетом всех HAVE_xxx и наших переопределений. RT> А то сейчас уже RT> начинает наблюдаться бардак. "sys.h" постепенно обрастает хаками и редефайнами стандартных функций, между тем часть RT> модулей его включало, часть не включало, часть включало опосредованно на хз-каком уровне вложенности из другого инклуда RT> в неизвестно каком порядке по отношению к переопределяемому термину, и т.п. Hекоторое время назад я уже заловил RT> переопределение O_BINARY в 0 там, где он должен быть ненулевым (хорошо, этот модуль его вроде не использовал) и считаю, RT> что подобный бардак надо пресекать в зародыше.
По идее, там должно определяться только то, чего нет в системе. Тот же O_BINARY определяется после "#ifndef O_BINARY". Если в системе нет понятия "binary", т.е. всё и так по умолчанию открывается как binary, то O_BINARY логично определять именно в 0, чтобы не возникло проблем - разве нет? Как иначе?
Стандартные функции и константы действительно не должны редефайниться в sys.h. Но этого, кажется, и не делается. Те инклуды, которые затрагивает sys.h, должны в нём и включаться - и они включаются, это unistd.h, io.h, process.h и т.д. Те, которые никак не используются в sys.h, туда добавлять на мой взягляд незачем (тот же stdio.h).
Lucky carrier, Паша aka gul@gul.kiev.ua --- GoldED+/LNX 1.1.5 * Origin: printf("%s", "How can I increase performance?\n"); (2:463/68)
