- 1
- 2
- 3
- 4
- 5
fi = fopen("kokoko.tmp", "rb");
fseek(fi, 0, SEEK_END);
file_size = ftell(fi);
fseek(fi, 0, SEEK_SET);-
Си / Говнокод #17892
+131
rewind? system call? Не, не слышали.
Запостил:
codemonkey,
30 Марта 2015
Follow us!
Как узнал?!
В общем-то очередная сишкоблядская проблема: если файл больше двух гиг, то можно забыть о кроссплатформенных fseek()/ftell(). Придётся хуярить ifdef'ы и платформозависимые костылики.
POSIX?
man 2 open
man 2 lseek
man 2 stat
уже давно платформ не вижу где off_t все еще 32 бита.
ЗЫ С стандарт всегда слегка кривым и отстающим был, потому что хотят максимальной портабельности. с одной стороры. с другой, за годы практики, файлы больше 2Г видел крайне редко.
ЗЗЫ и на 64бит *нихах, лонг он 64бита. все нормальные 64бит платформы LP64.
Ну вот скомпилил сейчас в бубунте прогу с -m32, получил sizeof(off_t) == 4. -D_FILE_OFFSET_BITS=64 всё-таки ещё нужно передавать.
> POSIX?
Винда умеет в позикс без костылей типа цыгвина?
> все нормальные 64бит платформы
Ключевое слово - 64бит. На 32-битках лонг коротковат.
Вроде бы да.
https://ru.wikipedia.org/wiki/Подсистема_для_приложений_на_базе_UNIX
Или гугли Interix.
И экзешники компилировать в специальный формат, и чтобы у пользователей программы эта хрень была установлена...
P.S. А для восьмёрки её, кажется, и вовсе нет.
Я через этот набор пытался подключить диск через nfs, кое-как с матом сделал, но возникла нерешаемая проблема с кодировкой. Пришлось забить.
На винде еще кто-то программирует не на Шарпе?
(Про цигвин... Называть цигвин костылём это оскорбительно для всех остальных в сравнении весьма приличных костылей.)
> > все нормальные 64бит платформы
> Ключевое слово - 64бит. На 32-битках лонг коротковат.
но на 32бит платформах - либо легаси, либо встроенщина - шансов встретить 2ГБ файл очень мало.
типичный пример это видео файлы. но видео-проигрывание само по себе уже не портабельно.
да, теоретически есть проблема. практически? - я чаще спотыкаюсь на FAT и его ограничения, нежели чем на то что прога обламывается на большых файлах. и насколько долга прога не пытается опрашивать размер файла, а просто последовательно его читает/пишет, то все работает.
Хуясе мало. Алсо про насы не слышал?
Ну да, но опосредованно- ещё как влияет. Пока дефайн не передашь - будет юзать 32-битные оффсеты.
... и пока в коде не начнешь правильно обращатся с потенциально 64 бит значениями.
по моему опыту, главные грабли в том что sizeof(off_t) != sizeof(long).
прикладники...
мы на 16бит процах с метром памяти работали. как это вообще возможно было!? магия?
>но на 32бит платформах - либо легаси, либо встроенщина - шансов встретить 2ГБ файл очень мало.
>но на 32бит платформах - либо легаси, либо встроенщина - шансов встретить 2ГБ файл очень мало.
Я говорю: пиздежь и провокация, подумай хотя бы о NAS, не говоря от 32 бит осях на десктопе
при чем тут NAS?
> не говоря от 32 бит осях на десктопе
при чем тут битность осей?
какое отношение это имеет к простому факту (который я констатировал) что файлы размером 2GB/более встречаются крайне редко?
редкому софту нужны большие файлы. (даже ДБ по умолчанию бьют тэйблспэйсы на мелкие файлы.) кроме видео я даже и другого примера навскидку припомнить не могу.
С таким же успехом можно написать, что "потребность в поддержке юникода крайне мала". Ты смотри на то,какой софт гарантированно не столкнется с файлами > 2gb.
И главное, блядь, почему вероятность встретить на 64 бит такие файлы больше?
А я этого и не говорил.
С другой стороны, есть народ который перелазил на 64бита специально для того что бы всякое такое в память пихать можно было без напряга.
Все, утомил.
Данные всяких бугхалтерских приложений, которые могут быть базой данных, а могут быть и просто файлами (но очень большими). Форматы для исследовательского ПО (геном какой-нибудь дрозовилы вполне может быть больше 2 гигов), ГИС (карты).
Охуенно часто встречаются.
Заебали вузовцы/научники считать себя пупом земли
во-вторых, я говорю о практическом опыте. насколько часто я видел гиговый файлы по работе и/или личной жизне.
а тут народ устроили какой-то глупый флейм как если бы я тут заявил что завтра конец света.
и самое главное, что в догонку к моему примеру видео, только один человек - один! - сумел привести еще один конкретный пример больших файлов (большие логи) в реальной жизни.
Это емейл. На тот момент больше такой хуйни нигде не было.
Тут просто мудак-разработчик на всякий пожарный экранировал символы, а деэкранировать забывал. Такое бывает.
И да, в теме этой питушне не место. По идее она должна появляться только в теле письма, да и то при условии, что тело в формате HTML.
Вполне возможно, что собеседник писал не через почтовую программу, а через веб-морду почтового сервиса. Были сервисы, которые все символы за пределами ASCII считали потенциально небезопасными.
лол. я юникоды как и большие файлу уж как 15+ лет делаю.
и вопрос был не конкретно о больших файлах - а об портабельном интерфейсе для больших файлов.
по вашей детской неспособности соосредоточится на топике, я догадываюсь что ваша голова все еще напичкана наивными идеалами.
... и читать в добавок не умеешь.
Исходя из этого, их поддержка не нужна?
Исходя из этого, если портабельность имеет приоритет, поддержка больших файлов опциональна.
годы, десятилетия проходят, а прикладники как были так и остаются тупой лимитой.
http://govnokod.ru/17892#comment269457
Сишники как были, так и остаются байтодрочерами, в отличие от господ высокого уровня, которым не приходится растягивать свою память, чтобы она вмещала костыли под все платформы.
теоретически, да. практически, никогда не пробовал. туториалы на сети лежат - сложного там ничего не видел. но тема меня не привлекает.
> в отличие от господ высокого уровня, которым не приходится растягивать свою память, чтобы она вмещала костыли под все платформы.
я 5+ лет под виндами работал - дельфи, билдер и вижуал. ушел на линухи как раз потому что задрало "растягивать свою память, чтобы она вмещала костыли", и это только *под одну платформу*. потому что граблей совместимости между версиями виндов разложено щедро.
В 90-х? Про языки с гц не слышал?
3 года жабы.
и хез знает сколько лет скриптовых языков (перл, питон, нынче еще руби трогать приходилось).
гц, как и его алгоритмы тема нетривиальная - но однозначно не непостижимая.
Вот и отлично, теперь сравни с жавой изъябства по правильному открытию файлов и расскажи мне теперь про "прикладников"
да и как раз в жабе, с открытием файлов случаются проблемы, если файлы забывать закрывать, потому что GC их хез когда только закроет.
>да и как раз в жабе, с открытием файлов случаются проблемы, если файлы забывать закрывать
А в си не случается? Там и гц нету-то.
почти тоже самое в С: если нужна портабельность, подключашь либу для портабельного ОС интерфейса.... и все. на больших проектах, с высокой вероятностью, уже все давно подключено и ничего специально делать не надо.
Видеопроигрывание непортабельно? Хорошо. Но есть ведь видеоконверторы типа FFMPEG, которые очень даже портабельны; есть программы для вычисления контрольных сумм; есть всякие качалки.
и они всегда были "портабельны" на винды потому что там есть кучка мелких #ifdef WIN32. и еще раз, насколько долго ты не опрашиваешь размер файла (просто последовательно читаешь/пишешь) все будет работать.
и если вы уже хотите портабельности, то с виндами большие файлы это вообще мелочи. я в прошлом народу помогал портировать либу которая очень активно (по моему совету) пользовалась snprintf(). из всех шести (или больше?) вариантов этой функции на виндах, все кривые и нет ни одного прямого. почему пришлось несколько дней весь проект обкладывать #ifdef WIN32 (потому что на тот момент еще не было прокладки для портабельности а запускаться уже надо было).
а вы про большие файлы...
Кстати, в каком ГК мы это обсуждали?
Кроссплатформенность не предусматривается.
Придирка, имхо. Что rewind(fi), что fseek(fi, 0, SEEK_SET) эквивалентны.
Про stat(), пожалуй, соглашусь. Раз кроссплатформенность не требуется.
P.S. Хотя сам я всю жизнь замерял через пару lseek()'ов... stat(), вроде как, дороже обойдётся, если файл всё равно открыли и собираемся читать/писать.
Идет цикл open/llseek/read/close для каждого вызова, а там их миллионы.
А зачем нужна такая тонкая абстракция над файлами? Если она действительно нужна, почему уж не сделать её правильно:
Немного оффтоп, но какую ПЛИС'ку юзаете?