Проблемы с запуском 32-битного демона на 64-битной машине

#define int __int32_t

Да ты просто кладезь быдлокода )

Виновато ли выравнивание - можно проверить с помощью __attribute__((packed)). Скорее всего, виновато.

Да ты просто кладезь быдлокода )

А как я тебе однозначно дам определение знакового 32-битного целого, чтобы оно и на 32-битной, и на 64-битной машине одинаково выглядело?

Виновато ли выравнивание - можно проверить с помощью __attribute__((packed)). Скорее всего, виновато.

Сейчас проверю.

И действительно: теперь эта шняга 1394 байт занимает. Но все равно откуда-то берутся лишние 14 байт...

Так и давай, по стандарту: int32_t. Переопределять ключевые слова - это же финиш. У тебя все стандартные функции, которые с интом работают, уже имеют право слететь.

Вложенные структуры тоже надо паковать, отдельно.

А с uint'ом как быть?

ошибка: unknown type name <<uint32_t>>

Доупаковывался: теперь размер структуры 1378 байт... Куда-то 2 байта «потерялось».

#include <stdint.h> ?

ты stdint.h подключил? У меня что-то в последнее время чтение Development адово поднимает самооценку.

Вот же черт! Все уже сделано до нас! ☺ (никогда им не пользовался)

Подключил, закомментировал свои define'ы - все равно куда-то 2 байта «потерялись»...

А в 32-битной версии данные в структуре выравнивались? Если да, то 2 байта в ней могли появиться как раз за счет этого.

И еще вот: http://www.rsdn.ru/forum/cpp/3368697.flat.aspx может поможет чем-то.

Значит, паддинг уже был на 32 битах где-то. Тебя ждёт увлекательная жизнь человека, не продумавшего сетевой протокол ;)

Ну или просто пересборка телескопа с теми же хаками.

Тебя ждёт увлекательная жизнь человека, не продумавшего сетевой протокол

а вообще всегда стоит бить по рукам людям, которые POD-структуры (де)сериализируют (для передачи по сети) через memcopy? Или так таки иногда можно?

А в 32-битной версии данные в структуре выравнивались?

Нет.

И еще вот: http://www.rsdn.ru/forum/cpp/3368697.flat.aspx может поможет чем-то.

Ой, спасибо!!!

[code] #pragma pack(4) [/code] решило проблемы

#define int __int32_t
#define uint __uint32_t

Могучий и ужасный Си.

По стандарту C - надо бить. Если хорошо понимают, что такое выравнивание полей структур, и умеют им управлять - то как бы и можно. Может, выйдет чуть быстрее. Но это всё равно привязка к платформе и лишняя морока, накой оно надо?

По вышепривёденной ссылке товарищ таки перешёл на работу с отдельными полями. А ТС по привычке предпочёл взять оттуда костылик для себя )

Алгоритм передачи мультикастов писал не я. И писался он 100500 лет назад. На него завязано такое количество сервисов, что нужно сказать так: серверная часть не обсуждается.

думаетца - паковку структуры надо + выравнивать добавлением пустых полей - до той структуры - которая правильная

и вообще - поля для внешнего формата лучше читать побайтно

Велосипед, как я уже выше говорил, не мой. Понятное дело, что стоило бы такую штуку делать с унификацией типов и выравниванием по 8 байт (например).

тогда правь струкуту - путем добавления пустых полей - чтоб она стала аналогичной старой

найди где-нибудь побайтное описание протокола, и сделай всё с начала по человечески. иначе всё равно не заработает, инфа 146%.

Исходники есть. Проблема в подгонке.