Ada_Ru форум

Обнаружил глюк в Os_Lib при работе с файлами.

Используя Creat_File (или Create_New_File) создаю файл. Затем записываю командой Write в него запись размером 20 байт. После чего закрываю файл командой Close. Команда Write выдала в результате 20, на всякий случай вставил File_Length перед Close - 20. Смотрю на файл средствами ОС (команда ls и тп) - размер файла 8GB !!! Причем первые 20 байт мои )

 

-- С уважением,

Алексей Ю. Уласевич

(A.STAKANOV)

http://www.livejournal.com/users/a_stakanov/

Aleksey Ulasevich пишет:

 

Обнаружил глюк в Os_Lib при работе с файлами.

Используя Creat_File (или Create_New_File) создаю файл. Затем записываю командой Write в него запись размером 20 байт. После чего закрываю файл командой Close. Команда Write выдала в результате 20, на всякий случай вставил File_Length перед Close - 20. Смотрю на файл средствами ОС (команда ls и тп) - размер файла 8GB !!! Причем первые 20 байт мои )

 

Прошу прощения. Просто я некорректно использовал LSeek перед Write. Теперь все ОК. )

 

-- С уважением,

Алексей Ю. Уласевич

(A.STAKANOV)

http://www.livejournal.com/users/a_stakanov/

Aleksey Ulasevich wrote:

 

Обнаружил глюк в Os_Lib при работе с файлами.

Используя Creat_File (или Create_New_File) создаю файл. Затем записываю командой Write в него запись размером 20 байт. После чего закрываю файл командой Close. Команда Write выдала в результате 20, на всякий случай вставил File_Length перед Close - 20. Смотрю на файл средствами ОС (команда ls и тп) - размер файла 8GB !!! Причем первые 20 байт мои )

 

Прошу прощения. Просто я некорректно использовал LSeek перед Write. Теперь все ОК. )

 

Вот поэтому и не стоит использовать нестандартные Ada пакеты :)

 

Адские средства ввода-вывода даже на сегодняшний день остаются весьма прогрессивными: они включают и текстовый ввод-вывод, и посделовательный типизированный, и прямой типизированный, и последовательный поточный (нетипизированный).

 

Использование остальных способов - однозначно не несть хорошо!

 

-- Vadim Godunko

 

Technoserv A/S

Rostov-on-Don, Russia

On Mon, Aug 15, 2005 at 11:53:46AM +0400, Vadim Godunko wrote:

 

Адские средства ввода-вывода даже на сегодняшний день остаются весьма прогрессивными: они включают и текстовый ввод-вывод, и посделовательный типизированный, и прямой типизированный, и последовательный поточный (нетипизированный).

 

 

Расскажите мне, как правильно читать двоичные файлы.

Например zip-архивы, формат которых описан в терминах

байтов. Или xml-файлы, кодировка которых заранее не

известна (по сути ведь тоже последовательность байт,

значение которых преобразуются в символы после

использования процедуры раскодирования).

 

Самый простой вариант - читать их как поток Character

наверное не есть самый правильный.

 

Более логичным кажется чтение через Stream_IO как

набор Stream_Element, но вот беда, нет гарантии,

что Stream_Element это байт. А вдруг это пол байта,

или два? И в каком они порядке? Читать этим способом

в его общем виде становится жутко неудобно.

 

 

--

Maxim Reznik

Maxim Reznik wrote:

 

Расскажите мне, как правильно читать двоичные файлы.

Например zip-архивы, формат которых описан в терминах

байтов. Или xml-файлы, кодировка которых заранее не

известна (по сути ведь тоже последовательность байт,

значение которых преобразуются в символы после

использования процедуры раскодирования).

 

Самый простой вариант - читать их как поток Character

наверное не есть самый правильный.

 

Точнее - самый неправильный.

 

Более логичным кажется чтение через Stream_IO как

набор Stream_Element, но вот беда, нет гарантии,

что Stream_Element это байт. А вдруг это пол байта,

или два? И в каком они порядке? Читать этим способом

в его общем виде становится жутко неудобно.

 

А почему не через Sequential_IO?

 

Тому точно можно скормить

 

type Octet is mod 2 ** 8;

for Octet'Size use 8;

 

 

--

Vadim Godunko

 

 

 

 

Vadim Godunko п©п╦я┬п╣я┌:

 

Maxim Reznik wrote:

п▒п╬п╩п╣п╣ п╩п╬пЁп╦я┤п╫я▀п╪ п╨п╟п╤п╣я┌я│я▐ я┤я┌п╣п╫п╦п╣ я┤п╣я─п╣п╥ Stream_IO п╨п╟п╨

п╫п╟п╠п╬я─ Stream_Element, п╫п╬ п╡п╬я┌ п╠п╣п╢п╟, п╫п╣я┌ пЁп╟я─п╟п╫я┌п╦п╦, я┤я┌п╬ Stream_Element я█я┌п╬ п╠п╟п╧я┌. п░ п╡п╢я─я┐пЁ я█я┌п╬ п©п╬п╩ п╠п╟п╧я┌п╟, п╦п╩п╦ п╢п╡п╟? п≤ п╡ п╨п╟п╨п╬п╪ п╬п╫п╦ п©п╬я─я▐п╢п╨п╣? п╖п╦я┌п╟я┌я▄ я█я┌п╦п╪ я│п©п╬я│п╬п╠п╬п╪

п╡ п╣пЁп╬ п╬п╠я┴п╣п╪ п╡п╦п╢п╣ я│я┌п╟п╫п╬п╡п╦я┌я│я▐ п╤я┐я┌п╨п╬ п╫п╣я┐п╢п╬п╠п╫п╬.

п░ п©п╬я┤п╣п╪я┐ п╫п╣ я┤п╣я─п╣п╥ Sequential_IO?

 

п╒п╬п╪я┐ я┌п╬я┤п╫п╬ п╪п╬п╤п╫п╬ я│п╨п╬я─п╪п╦я┌я▄

 

type Octet is mod 2 ** 8;

for Octet'Size use 8;

 

п░ Direct_IO я█я┌п╬ п╫п╣ я│я┼п╣я│я┌?

 

--

п║ я┐п╡п╟п╤п╣п╫п╦п╣п╪,

п░п╩п╣п╨я│п╣п╧ п╝. пёп╩п╟я│п╣п╡п╦я┤

(A.STAKANOV)

http://www.livejournal.com/users/a_stakanov/

Aleksey Ulasevich wrote:

 

А Direct_IO это не съест?

 

Direct_IO съест, но эффект будет произвольный ;)

 

Дело в том, что для Direct_IO не обязательно файл будет представляться как последовательность Octet. Дело в том, что если "умной" реализации скармливаешь дискриминантный тип, скажим вида:

 

type S (L : Natural) is record

N : String (1 .. L);

end record;

 

то она может построить индексную таблицу и "уплотнять" файл.

 

И никаких гарантий никто не даёт.

 

 

--

Vadim Godunko

On Mon, Aug 15, 2005 at 09:51:04PM +0400, Vadim Godunko wrote:

 

А почему не через Sequential_IO?

 

Тому точно можно скормить

 

type Octet is mod 2 ** 8;

for Octet'Size use 8;

 

 

Медлено... В Stream_IO можно прочесть сразу массив

любой длины, а в Sequential_IO прийдется читать по

одному байту.

--

Maxim Reznik

Maxim Reznik wrote:

On Mon, Aug 15, 2005 at 09:51:04PM +0400, Vadim Godunko wrote:

 

>А почему не через Sequential_IO?

 

>Тому точно можно скормить

 

>type Octet is mod 2 ** 8;

>for Octet'Size use 8;

 

 

 

Медлено... В Stream_IO можно прочесть сразу массив

любой длины, а в Sequential_IO прийдется читать по

одному байту.

 

Не спорю, но ведь суперпортируемость заказывали? Про эффективность речи не было ;)

 

 

--

Vadim Godunko

On Mon, 15 Aug 2005 20:03:32 +0300, Maxim Reznik <yeo@...> wrote:

 

On Mon, Aug 15, 2005 at 11:53:46AM +0400, Vadim Godunko wrote:

 

Адские средства ввода-вывода даже на сегодняшний день остаются весьма

прогрессивными: они включают и текстовый ввод-вывод, и посделовательный

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

(нетипизированный).

 

 

Расскажите мне, как правильно читать двоичные файлы.

Например zip-архивы, формат которых описан в терминах

байтов. Или xml-файлы, кодировка которых заранее не

 

XML это вроде текст. Причем намекалось что будет

работать через каналы вроде е-майла где и все 8 бит

не всегда проходят...

 

известна (по сути ведь тоже последовательность байт,

значение которых преобразуются в символы после

использования процедуры раскодирования).

 

Самый простой вариант - читать их как поток Character

наверное не есть самый правильный.

 

Более логичным кажется чтение через Stream_IO как

набор Stream_Element, но вот беда, нет гарантии,

что Stream_Element это байт. А вдруг это пол байта,

или два? И в каком они порядке? Читать этим способом

в его общем виде становится жутко неудобно.

 

Ну а двоичные данные вроде zip читать с упором

на машинно-зависимые особенности - как блоки байтов,

например. Причем блоковыми функциями - иначе тормозить

будет жутко.

 

Как раз то место где высокоуровневые средства языка

только мешают. (впрочем в исполнении API SB криворуких

Ц-ников почему-то данные на SB передаются по байтам - руки

бы оторвать этим извращенцам и недоучкам :/ )

 

Но проблем тут нет - такие машино-зависимые куски

в общем-то не большие, дальше уже если надо можно

определить процедуры более высокого уровня уже в любых

более удобных терминах...

 

Терминология.. ну тоесть типы будут уже зависеть от того

в каких терминах пытались писать программу.

 

Vladimir

PS В паскале это ускорялось через процедуры setTextBuf,

увеличивали размер буферов, далее операции через обход

типов... По сравнению с "правильным" посимвольным

чтением быстрее раз в 10 или более. Можно еще через

блоковые операции чтения, но там уже самому всякие текстовые

команды реализовать бы пришлось...

Так что более правильная либа для этого - та которая

учитывает аппаратные особенности и потому быстрее.

-- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/