Выпуск новостей ReactOS № 79

Z98, “ReactOS Newsletter: Newsletter 79”, public translation into Russian from English More about this translation.

See also 92 similar translations

Translate into another language.

Participants

evilslon 684 points
smerch 126 points
Ykidia 23 points
And others...
Join Translated.by to translate! If you already have a Translated.by account, please sign in.
If you do not want to register an account, you can sign in with OpenID.
Pages: ← previous Ctrl next
1 2

ReactOS Newsletter: Newsletter 79

Выпуск новостей ReactOS № 79

History of edits (Latest: evilslon 6 years, 7 months ago) §

— Перевод окончен и опубликован (http://www.reactos.org/ru/newsletter_...), всем спасибо за помощь! :) evilslon

The ReactOS team would like to wish everyone a merry Christmas and a happy New Year.

Команда ReactOS желает всем счастливого Нового года и Рождества.

History of edits (Latest: evilslon 6 years, 7 months ago) §

Coverity Redux

Статический анализ в Coverity

History of edits (Latest: evilslon 6 years, 6 months ago) §

The ReactOS team recently ran another Coverity scan on the source code. While a few new issues were discovered thanks to enhancements to Coverity's analysis program, the vast majority of issues fell into two categories; false positives due to the way the Portable Structured Exception Handling (PSEH) library is implemented and used, and warnings from third party code not developed by this project. Setting ignore on the PSEH usage should hopefully reduce such false positives in future scans but problems discovered in third party code is another matter entirely. Some projects we import from also submit their code for Coverity scans so in such instances it is their responsibility to fix any issues uncovered, though the ReactOS developers will submit bug reports or patches if we see no action on their part. Other projects however are not part of the scanning program and the team is contemplating relaying relevant result data to them to help with their development.

Недавно команда ReactOS вновь воспользовалась программным обеспечением компании Coverity для статического анализа исходного кода проекта. Хотя благодаря усовершенствованиям в алгоритме сканера Coverity в коде ReactOS и было найдено несколько новых ошибок, однако подавляющее большинство обнаруженных проблем разделилось на две категории: ложные срабатывания из-за способа реализации и использования портируемой библиотеки структурированной поддержки исключений (PSEH), а также сообщения о некорректности стороннего кода, не разрабатываемого в рамках данного проекта. Мы надеемся, что настройка анализатора на игнорирование факта использования PSEH снизит количество ложных срабатываний при последующих сканированиях, однако проблемы, обнаруженные в стороннем коде - это совершенно другой вопрос. Некоторые сторонние разработчики, код которых мы используем в ReactOS, также направляют свой код в Coverity для анализа, поэтому вся ответственность по исправлению обнаруженных ошибок лежит в первую очередь на них, хотя разработчики ReactOS готовы предоставить отчёты об ошибках или патчи, если мы не увидим с их стороны каких-либо действий по устранению этих ошибок. При этом остальные проекты не используют систему анализа исходного кода, и команда ReactOS постарается предоставить им полученные в результате сканирования данные, чтобы помочь им в разработке.

History of edits (Latest: evilslon 6 years, 6 months ago) §

— Разве речь идет о компании Coverity, а не о ее программном решении?  smerch

A few new issues were discovered by the latest scan and a steady stream of commits referencing Coverity scan IDs has flowed since then and the interested can review the SVN logs to see what has been fixed. Many of the issues dealt with incorrectly sizing something when doing memory operations, so data got overwritten or were written to the wrong location. One of the more interesting issues uncovered by Coverity is detailed below.

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

History of edits (Latest: evilslon 6 years, 6 months ago) §

— 2 elvison. referencing - в данном случае используется как "адресуемые". Потому, что коммит не ссылается на проблему (идентификатор), а адресован ей (т.е. является решением). smerch

— А мне кажется, что здесь имеется ввиду что в тексте коммит-месседжа имеется отсылка (ссылка на № CID) к конкретному CID, что позволяет понять, какой CID исправляет данный коммит. evilslon

...напр. мессадж коммита 50140: "Initialize next field. Fixes CID 11063" тут: http://www.reactos.org/archives/publi... evilslon

FASTFAT Buffers

Буферы FASTFAT

History of edits (Latest: evilslon 6 years, 7 months ago) §

The old FAT driver cropped up as a troublespot in the Coverity scans and stood out because the scan found both an overflow and overrun in a buffer the driver was using. And overflow basically means writes to the buffer are going beyond the size allocated to that buffer, whereas overruns happen when indexing of the buffer is done in a way that overshoots the size of the buffer. Both have the same effect of writing outside the buffer. Pierre Schweitzer investigated and discovered that for some reason there exists three separate buffers in the FAT driver that were being used for the same purpose. The consequence of this is that in certain operations, it would become unclear as to which buffer was actually being used. Whether the contents of the buffers were ever synchronized was also an open question and so the success of operations that relied on these buffers becomes hard to determine.

Сканирование в Coverity выявило, что старый драйвер FAT является "проблемным местом", поскольку в нём были обнаружены ошибки, связанные с переполнением буфера и приводящие к выходу за пределы выделенной для этого буфера области памяти. Пьер Швейцер (Pierre Schweitzer) исследовал код и обнаружил, что по какой-то причине в драйвере FAT имеется три разных буфера, используемых для одной цели и при некоторых операциях было невозможно определить, какой из буферов используется в данный момент. Синхронизировались ли они вообще? На этот вопрос так и не нашлось ответа, поэтому результат операций, использующих эти буферы, довольно сложно определить.

History of edits (Latest: evilslon 6 years, 6 months ago) §

— 2 elvison, про индексацию, пожалуйста, по-подробнее. smerch

— 2 smerch: Это просто прямой перевод "...indexing of the buffer is done...", если есть точный русский перевод этого термина - ссылку в студию (мне найти его не удалось). P.S. В польском переводе эти термины переводчик вообще не стал расписывать, ограничившись лишь "переполнением буфера". Я вот думаю, может и нам так сделать? ;) evilslon

More 4 comments

— Изменил предложение, теперь оно ближе к истине ;) evilslon

Pages: ← previous Ctrl next
1 2

© ReactOS Team.