информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Атака на InternetЗа кого нас держат?Spanning Tree Protocol: недокументированное применение
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Бэкдор в xz/liblzma, предназначенный... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
[C++ Bug] побазарим о другом ? 24.07.01 03:33  Число просмотров: 915
Автор: kabanchik Статус: Незарегистрированный пользователь
Отредактировано 26.07.01 00:15  Количество правок: 1
<"чистая" ссылка>
2 ALL. вынужден подправить мои синтаксические ошибки, чтобы не вводились в заблуждение. теперь все код остается только компилить

> да кто тут говорит о дергании - достаточно повышенной
> солнечной радиации в этом месяце и жаркой погоды, чтобы
> изменить пару бит по случайному адресу (опять же
> пресловутые законы Мерфи). Думаешь зря чтоли существуют
> соответствующие технологии (RAM ECC, SFT level XXX, etc...)

ВАУУУУ......., ребята, по моему вы очень далеко от темы ушли. тем более что друг друга обливать начали, не хорошо как то получается - перебор идет. прям как депутаты перед выборами :-)
с вашей фантазией такое наворотить можно, что страшно подумать.
а если завтра ядерная война - так давайте перейдем на счеты. или нет сорри, они сгореть смогут, лучше забросим писать коды ;-)

кстати, насчет заработок - странная штука, если кто то делает бабки, значит барыга. уметь надо даже из ГАВНА бабки делать - это, господа, не каждому дано и вы со мной согласны (я сам завидую таким). и не надо говорить о высоких материях и нравах, все равно не восприму. или скажете что принадлежите к категории - вы нас хлебом не кормите, дайте только поработать.
и лучше сразу у dl-a спросить, за что он XR-у бабки отстегивает. вдруг ему более дешевый и "сердитый" вариант предложим. РЫНОК МЛЯЯЯ !!!!

Я вон XR-у тоже дань плачу. без шуток, вот пример тому
2 XR:
я скоро бутыль отборного коньяка вышлю, передадут cb когда вернется (он ща в отпуске). встретьтесь семьями и распейте. обещаю - такого в Москве точно не найдете, если таможня не отберет ;-)
да и еще - ты свой прокси не вырубай когда домой уходишь, а то на выходные у меня опять "кислород" перекрылся ;-)

> > > > > IsBadCodePtr
> > > > > IsBadReadPtr
> > > > > IsBadWritePtr
> > > достаточно и этого - умный схватит идею в
> комплексе.

угу - согласен не плохая вещь. только как быть с этим? на скока я понял изначально нужна была протекция от такого :

int main()
{
    int array[100];
    int *ptr = array;
    if (IsBadWritePtr(ptr, 102) != 0)
        printf("It is not safe to write data at index 101");
    else
        printf("It is safe to write data at index 101");
    ptr[101] = 20;
    return 0;
}

---
кстати, я его прогнал на Win2K, VC++ 6.0. вот результат после выхода из main :
First-chance exception in test.exe: 0xC0000005: Access Violation.

если заметили, большинство ф-ий используют нечто подобное - foo(LPBYTE lpBuffer, DWORD cbBufferSize); - если бы проблема была легкая, то второй парам никогда не использовали бы. и вообще - ВСЕ бы языки юзали указатель. а Жаба (i.e. Java) была бы бесподобна.

давайте ка знатоки, я вам код подкину более интерестный - она платформо и компиляторо не зависимая, т.е. с ума сходит везде ;-) за одно протестите - может у кого она нормально бегает.

=============================

// для наглядности содержимого классов Parrent и Child, использовал 
// переменные m_pParrent & m_pChild, какие значения у них после выхода
// из деструктора

#include <stdio.h>
#include <new.h>

#define TRACE(x) printf(x)

class Parrent
{
public:
    Parrent()
    {m_pParrent = new char[10];}    // for fun
    virtual ~Parrent()
    {if (m_pParrent != NULL) delete [] m_pParrent; m_pParrent = NULL;}
public:
    virtual void PrintMsg()
    {
        TRACE("This function called from class Parrent.\n");
    }

protected:
    char*    m_pParrent;
};

class Child: public Parrent
{
public:
    Child()
    {m_pChild = new char[30];}    // just for fun, dummy buffer
    virtual ~Child()
    {if (m_pChild != NULL) delete [] m_pChild; m_pChild = NULL;}

    char* m_pChild;
public:
    virtual void PrintMsg()
    {
        TRACE("This function called from class Child.\n");
    }

    void Magic()
    {
        this->~Child();
        new (this) Parrent;
        TRACE("Leave Magic.\n");
    }
};

int main()
{
    Child child;
    Child* pChild = &child;
    Child& rChild = child;

    child.PrintMsg();
    pChild->PrintMsg();
    rChild.PrintMsg();
    TRACE("\n");
    child.Magic();
    TRACE("\n");
    child.PrintMsg();
    pChild->PrintMsg();
    rChild.PrintMsg();

    return 0;
}

---

================================
кажись ничего не упустил.
прежде посмотрите внимательно, нет ли ошибок, может вы с чем не согласны. предскажите ответ. а потом можно и дебагером пройтись, чтоб всю прелесть заметить ;-) и попробуйте объяснить явление.
и если не против, давайте начнем с новой нитки, знатоки ;-)

шутка - немного бородатая :
сын прибегает к отцу программиста и спрашивает :
С: Папа, а почему солнче встает на востоке, а хаходит на западе?
Отец не отрывая пальцы от клавы, а глаза от монитора -
О: ты уверен в этом?
С: да!
О: проверял?
С: да.
О: ну и как?
С: каждый день такое
О: тогда я тебя умоляю, пока работает ничего не меняй, пусть так и остается.

а указатели, господа, - это самое прекрасное что есть в программировании и давайте его оставим как есть ;-)

Regards.

kabanchik.
<programming> Поиск 






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 1 s   Design: Vadim Derkach