Все работало прекрасно, пока однажды не ребутнули linux, который видимо загрузился с новым ядром и некоторые скомпилированные файлы стали работать странно.

Решил просто пересобрать глючные и тут выяснилось, что fopen с опцией "r" ("rt" ничего не меняет) + fread читают вроде как надо - бинарно, но оказывается раньше они читали по иному (как текст что ли).

Суть - есть некая утилита под виндой кодирующая файл. Алгоритм и "пароль" дешифровки известен, декодирую под Дебианом, но почему то считывание одного и того же файла происходит по разному (коды символов ЧАСТИЧНО в считанной строке получаю разные) - под виндой строка, под линуксом чистые бинарные символы.

Как правильно читать в "линуксах", чтобы получить аналогичное преобразование?
Не соображу никак...

Dimitry Sibiryakov,

да это понятно, виндовая утилита уже так сделана, мне нужно под нее подстроиться

вот пример как читает "на винде"
авторiDm9>'

как на самом деле выглядит бинарник
авторiDm !

как на самом деле выглядит бинарник
авторiDm !&

т.е. вопрос как получить такую же как первая строка?

например, должен быть символ в DEC 57, но по факту там бинарный DEC 32
где происходит преобразование не понимаю

Dimitry Sibiryakov,

хорошо бы конечно отдалить, но от чужой утилиты у меня только кусок кода на дельфи, где происходит просто TFileStream.Read и там уже строка ДРУГАЯ, нежели в бинарнике

наверное преобразование типов где то происходит, но где... и почему раньше работало, а после обновления этих линуксов перестало...

Dimitry Sibiryakov,

мне дали этот кусок от дельфи, чтобы я на gcc декодировку сделал, так что я не могу не выводить строкой, так сделано там, т.е. от TFileStream.Read мне некуда бежать, а почему он получает другую строку, не понимаю

petrav,

может и не реально, однако просто пересобранный стал больше где то на 3%
интереса ради скопировал на другой сервер - проблема та же

что то не получает он у меня двоичный, сделал просто


и вуаля - часть символов в Buf отличается от бинарника

Siemargl,

да это все понятно, не понятно почему вдруг после ребута дебиана работать перестало, опцию b я до этого не использовал, но и с ней ничего не меняется, т.е. раньше он должен был читать как текстовый файл по идеи, но разницы в fopen нет с каких ключом открыть.

может дело в кодировке!?

Siemargl,

гугл говорит в дельфи 7 ansi 1 байт, поэтому вроде как читаю в gcc как unsigned char

mayton,

может вы и правы, а что за обновление utf8 ?

Dimitry Sibiryakov,

да hex то понятно везде одинаковый, мне то надо чтобы в сях получался такой же результат как в дельфах, не важно верный он там или нет

mayton,

ru_RU.UTF-8

Dimitry Sibiryakov,

Хорошо, байты

Byte в дельфе = unsigned char???

добавляю переменные в вотч в дельфе и вывод printf("%u", p*) где unsigned char * p
местами совпадают, местами РАЗНЫЕ
как правильно сравнить???

Вот тут и надо смотреть в какой момент они становятся "РАЗНЫЕ". Может, они из разных
файлов читаются...

разные они сразу как только в дельфе


где правда p указатель на структуру, но это роли не играет, одни Byte одинаковые, одни разные относительно unsigned char
потому что код символа выходит, а они местами разные у этих типов
файлы одинаковые - я подменяю старую версию и новую - одна глючно (по крайней мере кодированный файл читает верно) но работает, вторая новая вообще не работает.

как еще сравнить кроме hex, который мне вообще не нужен (потому что он не используется в утилите чужой для шифрования), я не знаю.

Dimitry Sibiryakov,

структуры одинаковые по длине и порядку элементов, тут я ничего не менял когда работало
завтра сравню по hex побайтно, что считалось в дельфе, но что то мне подсказывает что там будет тоже самое, а отличие будет у Byte и unsigned char

спасибо за сочувствие )

наверное нельзя засовывать в string, но именно эта строка по Byte и выходит, даже если TFileStream.Read(p, 80), где p указатель на структуру и ее размер 80

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

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

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

зы. изначально странное поведение оказалось тем, что я на SQL сервере изменил алгоритм хранимой процедуры, это выяснилось как только я смог дойти с отладкой до этого участка )