The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Проект по автоматическому анализу кода в пакетной базе Debian

17.12.2010 11:41

В списке рассылки разработчиков Debian анонсирован проект DACA (Debian's Automated Code Analysis) по созданию системы автоматизированного анализа кода программ, представленных в активных репозиториях пакетов. В настоящий момент в рамках проекта разработаны две утилиты: cppcheck для статического анализа кода на языке C++ (выявление утечек памяти, преждевременного удаления объектов, обращение за пределы буфера и т.п.) и checkbashisms для выявления shell-конструкций, поддерживаемых только в bash.

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

В настоящее время проекту требуются добровольцы для исправления найденных при помощи новых инструментов ошибок и для проверки наличия ложных срабатываний. Так как подобные утилиты достаточно сильно нагружают CPU их активное использование по проверке всего архива пакетов Debian пока ограничено, например, из-за нехватки ресурсов пока не удается организовать проверку всех изменений в репозитории Debian Sid. Разработчики надеются, что после того как найдется спонсор, который сможет предоставить для работы DACA отдельный сервер, активность проекта заметно увеличится.

  1. Главная ссылка к новости (http://lists.debian.org/debian...)
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/29029-debian
Ключевые слова: debian, code, analyze, check, gcc
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (52) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, QuAzI (ok), 11:58, 17/12/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    bash-шизм. Как звучит. Прямо болезнь какая-то.
     
     
  • 2.3, nib952051 (ok), 12:21, 17/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    check for ba^Wschism xD
     
  • 2.10, reminux (ok), 15:35, 17/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    да-да, те, кто страдает башизмом - "башисты".
    а те, кто с этим борется - "антибашисты". :D
     
     
  • 3.13, pavlinux (ok), 17:05, 17/12/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    а кто изучает - "башологи"

     
  • 3.19, vle (ok), 17:57, 17/12/2010 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > да-да, те, кто страдает башизмом - "башисты".

    Шутки шутками, но я не раз видел, как буржуи говорят
    bashit.

    > а те, кто с этим борется - "антибашисты". :D

    Соответственно antibashit :-)

    А если еще серьезнее, то таки да, башизм -- это болезнь,
    трудноизлечимая с тяжкими последствиями. И башитов надо лечить.

     
     
  • 4.20, Michael Shigorin (ok), 18:06, 17/12/2010 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Лечить надо тех, кто ставит байтики выше людей.  Поэтому держи свой -1. :)
     
     
  • 5.35, vle (ok), 02:01, 18/12/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Лечить надо тех, кто ставит байтики выше людей.  Поэтому держи свой
    > -1. :)

    Выше "байтиков" я ценю профпригодность, доказанную на деле,
    и умение разговаривать с людьми. Так что получай минус и от меня :-P
    Ты уверен, что точно понял, на что отвечал? ;-)

     
     
  • 6.41, Michael Shigorin (ok), 21:49, 18/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Выше "байтиков" я ценю профпригодность, доказанную на деле,
    > и умение разговаривать с людьми.

    Это хорошие качества, но и в сумме -- не весь человек.  Сказать пытался то, что вместо клеймления "башизмами" продуктивней показывать хороший пример самому и улучшать то, что небезразлично -- а всех не заклеймишь, ну и не поймут просто.

    Также могу напомнить старый спор, который поднимался в т.ч. в статьях "the rise of 'worse is better'" и "'worse is better' is worse" -- что лучше: код, который совершенен, но к моменту своего релиза никому по сути не нужен (скажем, Hurd), или код, который не ахти, но зато востребован (скажем, Linux)?

    Меня вполне устраивают скрипты на bash при условии указания его интерпретатором в hashbang либо когда априори известно, что /bin/sh -- это вариант bash (например, когда скрипт в пакете и пакет предназначен для системы с таким свойством). [PS: ...в качестве IMHO разумного компромисса]

    > Так что получай минус и от меня :-P

    Спасибо ;-)

    > Ты уверен, что точно понял, на что отвечал? ;-)

    Не факт -- мож пошли в жабер при случае? (ну и взаимно)

     
     
  • 7.44, vle (ok), 22:34, 18/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Меня вполне устраивают скрипты на bash при условии указания его интерпретатором в
    > hashbang либо когда априори известно,

    Именно так я себе все и представлял.
    Ты не понял, что такое башизм и почему это плохо.
    У меня лично нет никаких претензий к скриптам на баше.
    Работают и прекрасно. Но будьте любезны ЯВНО указывать,
    что вам нужен именно bash, а не POSIX shell, который в /bin/sh.
    Так вот "башизм" -- это когда мне говорят, что оно написано на POSIX shell,
    а на самом деле нужен bash. И причина этому /bin/sh == bash
    на почти всех линупсах.
    Единственный "правильный" (из известных мне) Linux дистриб
    в этом отношении -- Debian, по вполне понятным причинам.
    Хорошее они начали дело. Жаль, что никто так и не подхватил особо.


     
     
  • 8.45, Michael Shigorin (ok), 22:50, 18/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Не-не, я теоретически понимаю А как ты думаешь, в чём причина такой причины Ну... текст свёрнут, показать
     
     
  • 9.48, vle (ok), 23:35, 18/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Причина такой причины, очевидно, в том, что в UNIX интерактивный шел всегда испо... текст свёрнут, показать
     
     
  • 10.50, Michael Shigorin (ok), 14:06, 19/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    На том и разойдёмся - ... текст свёрнут, показать
     
     
  • 11.51, vle (ok), 14:14, 19/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Разница в этом пункте была известна очень давно - ... текст свёрнут, показать
     
  • 5.36, vle (ok), 02:21, 18/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Лечить надо тех, кто ставит байтики выше людей.

    На LVEE-2010 я вскользь затронул в блице одну из своих поделок,
    вот эту http://sf.net/projects/pipestatus.
    Несколько людей заинтересовалось, завязалось в сторонке некоторое обсуждалово.
    Подошел господин П., тупой альтовец, прости господи, и начал втирать компании,
    "чтоб не выпендривались и взяли bash"(С), не удосужившись толком выяснить,
    о чем вообще идет речь. Тупой чурбан!

    Извини, Миша, я не сдержался, ты меня провоцируешь.

     
     
  • 6.42, Michael Shigorin (ok), 21:59, 18/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > [...] Тупой чурбан!

    Ну ты с bmake наперевес тоже лезешь во все щели, чем местами тоже делаешь "ему же" хуже, чем e.g. засветить интересный пример "на подумать" для тех, кому актуально.  Ну как Столман, когда очередную палку перегибает.

    Так ты ж от этого не "тупой нетобздюк", а просто _кажется_, что лучше так.  Даже той прогулки с длииииительным обсуждением, как показало перечитывание записок, оказалось недостаточно -- по крайней мере твоё суждение (позже в жабере) на поверку вышло поверхностным.  Это при том, сколько мы тогда проговорили и просмотрели -- и не ради того, чтоб тебя уязвить, а чтоб проиллюстрировать _трудоёмкость_ процесса хождения в чужих тапках.

    Вот смотри, не далее как в четверг со skif@ встретились на конторе да перекинулись, у кого что сейчас под руками творится -- так он зело радовался именно .for :-) (и при этом твои крузады не слышал -- а более полезным применением потраченного пороха могло бы оказаться, скажем, создание краткого наглядного вводного туториала)

    (btw по "П.": не соображу, кто бы такой там был "тупой" -- черкни опять же в жабер)

    > Извини, Миша, я не сдержался, ты меня провоцируешь.

    Лёш, это ты извини -- порой бывает и не всегда вовремя даю себе по рукам.  Не хотел.

     
     
  • 7.46, vle (ok), 23:05, 18/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >> [...] Тупой чурбан!
    > Ну ты с bmake наперевес тоже лезешь во все щели, чем местами
    > тоже делаешь "ему же" хуже, чем e.g. засветить интересный пример "на
    > подумать" для тех, кому актуально.  Ну как Столман, когда очередную
    > палку перегибает.

    О чем речь вообще, я не пойму. Я всего то один раз "всез", причем вежливо,
    практически с реверансами, за советом, и тут же получил
    "Я надеюсь, вы не только NetBSD фанатик/евангелист..."(C).
    Тьфу! Тупость какая.

    > оказаться, скажем, создание краткого наглядного вводного туториала)

    Туториала по чистому bmake-у у меня нет, и писать его мне некогда,
    своих погремушек полно.

    Хотя, меня то ли год, то ли два назад мучил Игорь Чубин.
    Где-то здесь компиляция моего ему письма на смежную тему.

    http://xgu.ru/wiki/make

    Да и не настолько bmake интересен в чистом виде.
    Гораздо интереснее mk-files, на нем написанные.
    Но у некоторых (на лин начинается, на ды заканчивается)
    NIH синдром, станут они на бздюковые поделки смотреть, щаззз.

    А интересные примеры "на подумать" я уже давал. Сильно больше одного.

    http://mova.org/~cheusov/pub/mk-configure/mkc-presentation.pdf

    Кому надо, тот и посмотрит. На систему сборки Ёрга Шилинга, того самого,
    у которого cdrtools и schillix, тоже стоит посмотреть. Тоже "на подумать",
    для общего развития. makefiles так и называется.

     
     
  • 8.47, Michael Shigorin (ok), 23:19, 18/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Понимаю Захватил в Download -- в следующий раз на стационаре будет и ещё чем ... текст свёрнут, показать
     
     
  • 9.49, vle (ok), 23:50, 18/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Типа послал - Лучше забей Ты хочешь обсуждать это здесь Сейчас Оно тебе над... большой текст свёрнут, показать
     
     
  • 10.52, Michael Shigorin (ok), 14:48, 19/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Нет и так офтопик возможно мне за тебя обидно А что гентушники один непод... большой текст свёрнут, показать
     
     
  • 11.53, vle (ok), 16:34, 19/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Башизмы вообще-то топик Но для обсуждения mk-c и make-ов место не очень подходя... большой текст свёрнут, показать
     
     
  • 12.54, Michael Shigorin (ok), 17:41, 19/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    PreScriptum Вероятно, лучше пока свернуть да обдумать Но по крайней мере я _х... большой текст свёрнут, показать
     
     
  • 13.55, vle (ok), 19:46, 19/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    ЧТД Миша, по данному вопросу тебе сказать решительно нечего Потому что ты ничег... большой текст свёрнут, показать
     
     
  • 14.56, Michael Shigorin (ok), 19:54, 19/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Вот врать не надо skip ещё три строки лучше уж лично ... текст свёрнут, показать
     
  • 5.38, Аноним (-), 18:21, 18/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Ты, наверное, на хабр заходил и видел, как там "замечательно" работает плюсоминусовалка... по-моему это инстумент шапкозакидательства для толпы.
     
     
  • 6.40, vle (ok), 18:53, 18/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Были такие телешоу: "Последний герой", "Слабое звено" и др.
    Они все показали уже тогда...
    Ну а Миша... Он же любя :-)
     
     
  • 7.43, Michael Shigorin (ok), 22:17, 18/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну а Миша... Он же любя :-)

    Именно :-)  Я очень уважаю тебя и твоё мнение, хотя как раз во мнениях мы нередко расходимся.

     

  • 1.2, klalafuda (?), 12:10, 17/12/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Для начала хотя бы собирайте C/C++ с флагами -W -Wall -Werror. И отзывайте мусор, который почему то не собираются. И то будет уже хорошо.
     
     
  • 2.7, тоже Аноним (ok), 13:02, 17/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Вчера анализировал программу CppCheck'ом. У меня создаются объекты (через new), которыми затем овладевают объекты из фреймворка, удаляя их в своем деструкторе. CppCheck анализирует мой код, а не библиотечный, и ругается на утечку памяти. Не подскажете, как это исправить, чтобы он не ругался?
     
     
  • 3.8, klalafuda (?), 13:44, 17/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Вчера анализировал программу CppCheck'ом. У меня создаются объекты (через new), которыми затем овладевают объекты из фреймворка, удаляя их в своем деструкторе. CppCheck анализирует мой код, а не библиотечный, и ругается на утечку памяти. Не подскажете, как это исправить, чтобы он не ругался?

    Чес слово - не знаю, уж простите :) Я не использую CppCheck. Мне и Valgrind-а вполне хватает.

     
  • 3.9, Толстый_ (?), 14:23, 17/12/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А какой фреймворк? ИМХО ошибка в дизайне.
     
     
  • 4.11, gegMOPO4 (ok), 16:33, 17/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Любой умный указатель.
     
  • 4.25, тоже Аноним (ok), 19:42, 17/12/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    wxWidgets
    Там, например, можно создать malloc'ом область в памяти, напихать туда всего, что нужно, а потом передать эту область в конструктор wxImage и дальше обрабатывать как картинку (масштабирование, замена цвета и т.п.). При этом объект wxImage овладевает памятью и удаляет ее сам, в своем деструкторе. Если картинка хороших размеров, то экономится выделение еще такого же куска памяти и копирование в него информации, оригинал которой все равно больше ни для чего не нужен.

    Ну, и обычное дело - создание контролов в конструкторе диалога просто как
    sizer->Add( new wxTextCtrl(this, ID_TEXT) );
    с полной уверенностью, что деструктор диалога эту память (на которую никакая пользовательская переменная не указывает) удалит, как дочернее для этого диалога окно.
    CppCheck этого, естественно, не знает.

     
  • 4.37, Aleksey (??), 13:36, 18/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    wxWidgets, Qt, Fox toolkit, да и вообще любой графический тулкит, который может создавать иерархии окон.

    CppCheck предоставляет крайне ограниченные возможности для такого вида настройки и дает слишком много ложных срабатываний. По сути он чуть-чуть лучше, чем -Wall

     
     
  • 5.39, тоже Аноним (ok), 18:28, 18/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    А с чего ему быть сильно лучше? Все, что можно сделать автоматически, стараются реализовать в компиляторе. Разница только в том, что, как я писал ниже, -Wall выдает не только мои грешки, но и все, что нашел в используемых классах библиотеки. А CppCheck ограничивается тем кодом, который ему указали.
     
  • 3.14, pavlinux (ok), 17:09, 17/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Вчера анализировал программу CppCheck'ом. У меня создаются объекты (через new), которыми
    > затем овладевают объекты из фреймворка, удаляя их в своем деструкторе.

    Так он объекты удаляет или delete делает?

    > CppCheck анализирует мой код, а не библиотечный, и ругается на утечку памяти.

    значит она там есть :)

    > Не подскажете, как это исправить, чтобы он не ругался?

    Один из примеров хорошего тона в программировании,
    это когда free (delete) делают там же, где  и malloc(new).

     
     
  • 4.15, gegMOPO4 (ok), 17:14, 17/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Это, очевидно, не всегда возможно. Иначе можно было бы обойтись автоматическими переменными.
     
     
  • 5.17, pavlinux (ok), 17:26, 17/12/2010 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > Это, очевидно, не всегда возможно. Иначе можно было бы обойтись автоматическими переменными.

    Это похоже на НКВД. Когда им Физмат МГУ выделил 10 учёных,
    на разработку секретного девайса. И по окончании работ
    НКВДшники всех их расстреляли. :)


     
     
  • 6.22, gegMOPO4 (ok), 19:25, 17/12/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Вы помирать приедете в тот же роддом, где и родились?
     
     
  • 7.27, pavlinux (ok), 20:22, 17/12/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Вы помирать приедете в тот же роддом, где и родились?

    Умереть можно где угодно, а решается это в одном месте. :)
    Ах да, и регистрируют рождение и смерть тоже в одной конторе.


    ---

    Жду следующего коммента, про то, что есть и срать в одном месте не хорошо.
    Но это уже к Джайверам, у них там сортир отдельно работает.


     
     
  • 8.29, klalafuda (?), 20:45, 17/12/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Павлинух, дорогой, открой для себя наконец boost shared_ptr и не сношай мозги ч... текст свёрнут, показать
     
     
  • 9.33, pavlinux (ok), 22:56, 17/12/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Мне-то оно нах я Ц не юзаю ... текст свёрнут, показать
     
     
  • 10.34, тоже Аноним (ok), 23:17, 17/12/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А едите вы тоже в этой ветке ... текст свёрнут, показать
     
  • 3.18, Андрей (??), 17:35, 17/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    сделай нормальный API (в своих либах), чтоб объекты удалялись там же, где и создаются.
     
  • 3.28, Аноним (-), 20:30, 17/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Ни один статический анализатор не пригоден для проверки утечек. Единственное адекватное решение — valgrind. Впрочем, статические анализаторы вообще мало для чего пригодны, по причине большого количества ложных срабатываний.
     
     
  • 4.30, тоже Аноним (ok), 21:28, 17/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Ну почему же, для черновой чистки кода, особенно после рефакторинга, когда классы обменивались членами и методами, вполне годится. Тут переменная уже не используется, тут - можно уменьшить ее область видимости, свичи без дефолтов лишний раз посмотреть - может, и нужно сделать... В общем, для "полировки" и в качестве имитации свежего взгляда - нормально. Как альтернатива ключам компилятора, в результате которых имеешь ворох замечаний, из которых 90% - вообще не к твоему коду, а к библиотечному.
     
     
  • 5.31, klalafuda (?), 21:54, 17/12/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Ну почему же, для черновой чистки кода, особенно после рефакторинга, когда классы обменивались членами и методами, вполне годится. Тут переменная уже не используется, тут - можно уменьшить ее область видимости, свичи без дефолтов лишний раз посмотреть - может, и нужно сделать... В общем, для "полировки" и в качестве имитации свежего взгляда - нормально. Как альтернатива ключам компилятора, в результате которых имеешь ворох замечаний, из которых 90% - вообще не к твоему коду, а к библиотечному.

    Неиспользуемые переменные прекрасно отсекает gcc. И в этом он совершенно прав. Если, допустим, неиспользуемые аргументы метода вполне имеют право на жизнь (соответственно -Wno-unused-parameter валиден и правомерен) то неиспользуемые переменные - это откровенный мусор. Естественно, если это простой тип.

    Свичи без дефолтов - тоже вполне валидны. При условии, что это перечисление и в свиче by design полный набор элементов. Это позволяет ещё на уровне компиляции обнаружить, что оказывается, перечисление внезапно! кто-то расширил новыми элементами а вот в селекторы тут там и сям их не добавил (забыл). Если бы стоял дефолт то компилятор бы это проглотил на ура. С самым разными последствиями.

    Ворох же замечаний - он в подавляющем большинстве случаев не просто так. И не суть важно откуда они идут - из кода A или из стороннего кода B. Какая разница где именно грязь === риски багов? Если оно есть - с этим нужно разбираться, без вариантов.

     
     
  • 6.32, тоже Аноним (ok), 22:47, 17/12/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Свичи без дефолтов - тоже вполне валидны

    Я имел в виду - лишний раз обратить внимание и спросить себя: не нужно ли этот свич заткнуть дефолтом? Точно ли перебраны все возможные варианты? Не всегда он сводится к перечислениям. Кстати, если невозможный дефолт заткнуть выбрасыванием исключения - код вовсе не испортится.

    > Какая разница где именно грязь === риски багов? Если оно есть - с этим нужно разбираться, без вариантов

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

     

  • 1.4, Аноним (-), 12:33, 17/12/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Мне кажется такой анализ невозможен. Чуть более запутанным код станет и уже ошибка никогда не будет найдена...
     
     
  • 2.5, Vitto74 (ok), 12:43, 17/12/2010 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Запутанный код - плохой код. Запутывать код для предотвращения срабатываний - геморрой и для себя и для других разрабов.
    Дьявол кроется в деталях. Именно мелкие ошибки, которые трудно заметить (заметить при чтении, а не найти во время аудита кода) становятся причинами серьезных проблем.
     
  • 2.6, тоже Аноним (ok), 12:57, 17/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Такой анализ, как мы видим по этим (и аналогичным) утилитам, возможен.
    Он несовершенен - это понятно. Если бы все ошибки можно было отлавливать автоматически, этим занимались бы компиляторы.
     

  • 1.12, Аноним (-), 16:33, 17/12/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    лучше бы очистили репозиторий от ненужного хлама, чем мериться у кого он самый большой.
     
     
  • 2.16, User294 (ok), 17:26, 17/12/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А то определит критерии нужности? Пушкин, Александр Сергеевич? А по каким критериям?
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру