Igor
Да и вообще все операции с файлами
Snusmumriken
Звучит как повод катать что-то типа: #ifdef WIN_32 mytype readfile() { } ...
Igor
Не помню уже почему откинул эту идею
Igor
Но наверное ща так и сделаю
Igor
А, вспомнил
Igor
Хендлы же файлов разные между виндовым и юниксовым стандартом
Igor
То есть файл открытый через OpenFile() виндовую не такой же, как тот, что открыт через fopen
Igor
Если я правильно помню
UtoECat
То есть допустим, если LuaJIT скомпилен через MSVC, а моя библа через MinGW кросскомпилом, то fread меня шлёт куда подальше
Я думаю что тут только через mingw попробовать luajjt перекомпилить? Такое возможно? 🤔 Потомушо любой иной гемор того не стоит...
Igor
Я думаю что тут только через mingw попробовать luajjt перекомпилить? Такое возможно? 🤔 Потомушо любой иной гемор того не стоит...
Да тут проблема-то не только в компиляторе... Если ещё например LuaJIT собран с дебаг-символами, а моя библиотека без, то тоже пососать отправляет
Igor
Потому что так тоже будут разные структуры у файла
Igor
Я какое-то время думал, что fopen, fclose, fread, fwrite, fseek это обёртки над виндовыми функциями, теми, что в ведре лежат
Igor
Но потом как-то попробовал хендл от fopen использовать в виндовых вызовах и что-то всё посыпалось
UtoECat
Ну в том, шо каждый свою libc статически линкованную тащит... да 💀
Тут только если тащить с собой кучу dll из x86_64-w64-mingw32/bin/
Igor
Это не решит её тоже
Igor
Проблема в том, что LuaJIT условный возвращает хендл файла от своего рантайма
Igor
А моя библиотека пытается работать с ним как с хендлом своего рантайма
UtoECat
Проблема в том, что LuaJIT условный возвращает хендл файла от своего рантайма
Ну так да, перекомпилить оба с shared libc, и использовать одну и ту же либу
Igor
Ну так да, перекомпилить оба с shared libc, и использовать одну и ту же либу
Ну моя либа может использоваться во многих сценариях, она ж публична
Igor
Не компилить же всем в таком виде постоянно своё всё
Igor
Нужно чтобы со всеми компилерами работало нормально
Igor
А это возможно? 😁
Ну, хотя бы со всеми ходовыми)))
UtoECat
Ну моя либа может использоваться во многих сценариях, она ж публична
Ну тебе в ином случае всё равно городить что-то на стороне luajit придётся) Не уверен что есть другой вариант. Потмушо даже ffi тебе вернёт динамическую либу, а не ту, с которой luajit статически слинкован, и там будет разный FILE* тоже...
Igor
Ну да, вот такой код уже не отрабатывает
Snusmumriken
Проблема в том, что LuaJIT условный возвращает хендл файла от своего рантайма
Ну смотри, если ты луажытом получаешь хендлер, то и работать с ним можешь луажытом. Ты можешь смело написать функции а ля lua_getglobal(L, "io"); lua_getfield(L, "open"); Или лезть в метатабличку переданного объекта и дёргать там read.
Igor
В буфер пишется 0xCC 0xCC 0xCC 0xCC
Snusmumriken
Даладна
Igor
Только код пожирнее станет, правда
Snusmumriken
Это да
Igor
У меня тут скомпоновано всё классненько
Igor
Хотя можно просто сделать чтобы функции возвращали нужные значения
UtoECat
Только код пожирнее станет, правда
Иначе только общая libc. Выбирай, так сказать 😁
Igor
И менять особо не придется ничего
Igor
В самой функции, имею ввиду
UtoECat
Хотя можно просто сделать чтобы функции возвращали нужные значения
А можно сделать так, чтобы на вход подавалось имя файла и забить) не так много в производительности потеряешь
Igor
короче что-то типа такого сделаю)))
Snusmumriken
Возня с луёвым стеком это и правда малясь морока, но это дело можно выделить во вспомогательные функции а ля: luaX_getmethod(L, "methodname", -1); И оно типа вытащит функцию, пропихнет объект первым аргументом и будет ждать следующих для вызова.
Igor
Я чет забыл, а f:read() может ошибку вернуть?)) Безопасно делать lua_call() с ним?
Snusmumriken
Оно именно возвращает ошибку а не рейзит еррор
Igor
Ну и хорошо
Snusmumriken
nil, error, два аргумента обработаешь
Igor
Не люблю я конечно дохрена жонглирования данными по буферам
Igor
Но тут придётся строчку из fread копировать в буфер
Igor
Хотя можно эту строку сразу возвращать, в принципе
Igor
Всё равно в пределах вызова этой функции она всегда валидна будет
Snusmumriken
Ну типа того.
Igor
Ой ладно, пока просто с копированием сделаю, а то код страшновато выглядеть будет)))
Igor
Строки в числа кастовать придется
Snusmumriken
Пока нет реальных проблем — читаемость > производительность.
Igor
Вроде должно работать, ща проверим
Igor
Ой, функция в топе же должна быть, ступил чета
Snusmumriken
Не принципиально, остальное починишь
Igor
Во, даже работает как надо
Igor
Давно я чет луи не трогал с сишной стороны, подзабылись уже некоторые моменты
Igor
Осталось обернуть fseek
Snusmumriken
Ну прост серьёзно, если ты получаешь объекты из определённой среды, то пущай эта среда с объектами и работает.
Igor
Ну так-то да
Snusmumriken
Тем более что всю кроссплатформу там уже внутри решили
Snusmumriken
Кстати, примерно по этим причинам обычно сишные библиотеки принимают пути до файлов а не сами файлы. Строчки в виде char *, к счастью, более-менее стандартны.
Igor
Вот финальные варианты, если кому интересно))
Igor
Вроде и заголовок читает правильно
Igor
И с ловкой крашиться перестало, ляпота
Snusmumriken
Snusmumriken
А если вдруг ощущаешь просадки производительности — просто реже считывай. Буфер побольше и вперед. Сишка действительно медленнее вызывает луашку чем луашка сишку, но вот насколько это критично — в каждом случае по своему, и как правило нет.
Igor
Это просто у меня бзик такой, не люблю неоптимальные решения))
Igor
Но оптимальные писать иногда как-то лениво
Snusmumriken
Я от этого вылечился на своей работе.
Snusmumriken
Там иногда такие сроки, что даже максимально неоптимальное решение может быть слишком медленным. И ничего, работает. А если приходят жалобы на скорость — это как правило не из-за скорости исполнения кода, а всякие ожидания что что-то внешнее отработает.
Snusmumriken
Правда, когда я только устраивался, я как-то по криворукости устроил отключение электричества в офисе. Забыл поставить sleep в цикле.
Igor
Ахахахаххаха