информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Где водятся OGRыЗа кого нас держат?
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Бэкдор в xz/liblzma, предназначенный... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
[C++ Bug] Bug report 25.07.01 03:08  Число просмотров: 890
Автор: Ван Мо Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Па-руски говоря у тебя написано так:
#include <stdio.h>

void* operator new (size_t size, void *ptr)
{
  return ptr;
}

class Parent
{
public:
  virtual void PrintMsg() { printf("This function called from class Parent.\n"); }
};
 
class Child: public Parent
{
public:
  virtual void PrintMsg() {	printf("This function called from class Child.\n"); }
  void Magic()
  {
    new (this) Parent;
    printf("Leave Magic.\n");
  }
};

int main()
{
  Child child;
  Child* pChild = &child;
  Child& rChild = child;
 
  child.PrintMsg();
  pChild->PrintMsg();
  rChild.PrintMsg();
  printf("\n");
  child.Magic();
  printf("\n");
  child.PrintMsg();
  pChild->PrintMsg();
  rChild.PrintMsg();
 
  return 0;
}

---
В результате имеем
This function called from class Child.
This function called from class Child.
This function called from class Child.

Leave Magic.

This function called from class Child.
This function called from class Parent.
This function called from class Parent.

---
Теперь так же па-руски объясни что ты хотел сказать конструкцией new (this) Parent;
<programming>
[C] отладка 17.07.01 21:15  
Автор: Анжелика Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Как в С++ обноружить выход за пределы границ массива и всякие разные плохие укозатели???

2dl: почему етот мудазвон admin@hoster.ru пастаянно просит меня прислать ему его долбаную ошибку??? Мля пусть он на той страничке кнопарь вставит и инпут знаков на десять не больше!
[C] отладка 18.07.01 22:31  
Автор: игппук Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> Как в С++ обноружить выход за пределы границ массива и
> всякие разные плохие укозатели???
>
> 2dl: почему етот мудазвон admin@hoster.ru пастаянно просит
> меня прислать ему его долбаную ошибку??? Мля пусть он на
> той страничке кнопарь вставит и инпут знаков на десять не
> больше!

как обнаружить выход за пределы массива? странный вопрос. если ты под винду пишешь, то она тебе сама об этом скажет путем ошибки доступа к памяти.
проверяй указатель на NULL. если он все таки неверен, то ты опять же получишь ошибку доступа.
а можешь воспользоваться блоков
try-catch для остлеживания таких ситуаций
[C] отладка 18.07.01 23:47  
Автор: Анжелика Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> > Как в С++ обноружить выход за пределы границ массива и
> > всякие разные плохие укозатели???
> >
> > 2dl: почему етот мудазвон admin@hoster.ru пастаянно
> просит
> > меня прислать ему его долбаную ошибку??? Мля пусть он
> на
> > той страничке кнопарь вставит и инпут знаков на десять
> не
> > больше!

>
> как обнаружить выход за пределы массива? странный вопрос.
> если ты под винду пишешь, то она тебе сама об этом скажет
> путем ошибки доступа к памяти.

Напиши под винду дорогой

int main()
{
  int a[4];
  a[4]=666;

  return 0;
}


---
> проверяй указатель на NULL.

с чего это он вдруг станет NULL?

> если он все таки неверен, то ты
> опять же получишь ошибку доступа.
> а можешь воспользоваться блоков
> try-catch для остлеживания таких ситуаций

с блоками праблем нет. как родить ошибку доступа?
[C] отладка 19.07.01 22:42  
Автор: игппук Статус: Незарегистрированный пользователь
<"чистая" ссылка>

> Напиши под винду дорогой
>

>
> int main()
> {
> int a[4];
> a[4]=666;
>
> return 0;
> }
>

с этим понятно. память в винде выделяются постраницно. размер страницы точно превышает 4 байта. если точнее, то размер страницы
равен 4 килобайта. потому код
int a[4];
a[100]=666;
тоже пройдет. все зависит от того, где у тя в этой странице конкретно массив расположен. если хорошенько извратнуться,
то можно сделать так, что последний индекс массива попадет на границу страници памяти. тогда если ты выйдешь за
пределы массива, то тогда точно получишь нарушение доступа))
[C] отладка 20.07.01 00:59  
Автор: дефлоратор Статус: Незарегистрированный пользователь
<"чистая" ссылка>
>
> > Напиши под винду дорогой
> >
> > 
> > int main()
> > {
> >   int a[4];
> >   a[4]=666;
> > 
> >   return 0;
> > }
> > 
> 
> с этим понятно. память в винде выделяются постраницно.
> размер страницы точно превышает 4 байта. если точнее, то
> размер страницы
> равен 4 килобайта. потому код
> int a[4];
> a[100]=666;
> тоже пройдет. все зависит от того, где у тя в этой странице
> конкретно массив расположен. если хорошенько извратнуться,
> то можно сделать так, что последний индекс массива попадет
> на границу страници памяти. тогда если ты выйдешь за
> пределы массива, то тогда точно получишь нарушение
> доступа))

---

сегодня будем делать второе упражнение
int main()
{
  int a[4];
  a[0x100000]=666;

  return 0;
}

---
шел бы ты рихтера читать милый :)
[C] отладка 23.07.01 21:33  
Автор: игппук Статус: Незарегистрированный пользователь
<"чистая" ссылка>

> сегодня будем делать второе упражнение
>
> int main()
> {
>   int a[4];
>   a[0x100000]=666;
> 
>   return 0;
> }
> 

---
> шел бы ты рихтера читать милый :)
я не полунился и проверил. крэш. ошибка доступа к памяти. все делал в вижуал с++. кстати, по поводу рихтера-почитай ка его сам)
как там память выделяется)
[C] отладка 24.07.01 04:56  
Автор: дефлоратор Статус: Незарегистрированный пользователь
<"чистая" ссылка>
>
> > сегодня будем делать второе упражнение
> >
> > int main()
> > {
> >   int a[4];
> >   a[0x100000]=666;
> > 
> >   return 0;
> > }
> > 

---
> > шел бы ты рихтера читать милый :)
> я не полунился и проверил. крэш. ошибка доступа к памяти.
> все делал в вижуал с++. кстати, по поводу рихтера-почитай
> ка его сам)
> как там память выделяется)

Будет ломаться где угодно, только не на 4K. Не будет ломаться если установлен ключ /Og (установлен по умолчанию для Release Config. MSVC6 Pro/Ent)
[C++] вариант решения... 19.07.01 14:43  
Автор: XR <eXtremal Research> Статус: The Elderman
Отредактировано 19.07.01 15:06  Количество правок: 4
<"чистая" ссылка>
> > > Как в С++ обноружить выход за пределы границ
> массива и
> > > всякие разные плохие укозатели???


> Напиши под винду дорогой
Но насчет ^^^^^^^^ это к cb :) его главное озадачить в ПРАВИЛЬНОМ направлении ...

>
> 
> int main()
> {
>   int a[4];
>   a[4]=666;
> 
>   return 0;
> }


> 
> 

---
> > проверяй указатель на NULL.
>
> с чего это он вдруг станет NULL?
>

Если речь идет о C++
то ...
#include <iostream>
template <class T>
class Safe
{
T    value;
int  protect;
public: 

Safe<T>(){protect=0x666;}
Safe<T>(T& a){protect=0x666;}
~Safe<T>(){protect=0x999;}

T& GetValue()   {return value;}

Safe<T>& operator = (const T a) throw(T)
 {
  if(protect!=0x666) throw a;
  value=a;
  return *this;
 }

friend ostream& operator << (ostream& os, Safe<T>& a) throw(T)
 {
  if(a.protect!=0x666) throw a.value;
  os << a.value;
  return os; 
 }
};

int main()
 {
   Safe<int> a[4];
   int b=2;
   // Проверяем на выход за границу массива   
   try {
        a[0]=1;
        cout << "a[0]=" << a[0] << "\n" << flush;
        a[1]=b;
        cout << "a[1]=" << a[1] << "\n" << flush;
        a[4]=666;
        cout << "a[4]=" << a[4] << "\n" << flush;
   } catch(int a)
   {
        cout << "Bad index !\n" << flush;
   }
   char xxx[40];
   memcpy(&a[1],xxx,sizeof(Safe<int>)*3);
   //Сейчас наши указатели указывают на "мусор"
   try {
        cout << "a[0]=" << a[0] << "\n" << flush;
        cout << "a[4]=" << a[1] << "\n" << flush;
   } catch(int a)
   {
        cout << "Bad pointer !\n" << flush;
   }
   
   return 0;
 }


---

Но все операторы придется написать самостоятельно, это несложно...
[C++] вариант решения... 21.07.01 03:15  
Автор: c0x@mail.ru Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Ну ты и нагородил!
Вместо того, чтобы использовать "умный" массив, ты предлагаешь на каждый экземпляр указываемого типа заводить некий флаг, который должен потвоемумнению отслеживать существует обьект или нет. Это же сплошная чушь.
Ну насмешил - век так не смеялся!


> > > > Как в С++ обноружить выход за пределы границ
> > массива и
> > > > всякие разные плохие укозатели???
>
>
> > Напиши под винду дорогой
> Но насчет ^^^^^^^^ это к cb :) его главное озадачить в
> ПРАВИЛЬНОМ направлении ...
>
> >
> > 
> > int main()
> > {
> >   int a[4];
> >   a[4]=666;
> > 
> >   return 0;
> > }
> 
> 
> > 
> > 

---
> > > проверяй указатель на NULL.
> >
> > с чего это он вдруг станет NULL?
> >
>
> Если речь идет о C++
> то ...
>
> #include <iostream>
> template <class T>
> class Safe
> {
> T    value;
> int  protect;
> public: 
> 
> Safe<T>(){protect=0x666;}
> Safe<T>(T& a){protect=0x666;}
> ~Safe<T>(){protect=0x999;}
> 
> T& GetValue()	{return value;}
> 
> Safe<T>& operator = (const T a) throw(T)
>  {
>   if(protect!=0x666) throw a;
>   value=a;
>   return *this;
>  }
> 
> friend ostream& operator << (ostream& os,
> Safe<T>& a) throw(T)
>  {
>   if(a.protect!=0x666) throw a.value;
>   os << a.value;
>   return os; 
>  }
> };
> 
> int main()
>  {
>    Safe<int> a[4];
>    int b=2;
>    // Проверяем на выход за границу массива   
>    try {
> 	a[0]=1;
> 	cout << "a[0]=" << a[0] << "\n"
> << flush;
> 	a[1]=b;
> 	cout << "a[1]=" << a[1] << "\n"
> << flush;
> 	a[4]=666;
> 	cout << "a[4]=" << a[4] << "\n"
> << flush;
>    } catch(int a)
>    {
> 	cout << "Bad index !\n" << flush;
>    }
>    char xxx[40];
>    memcpy(&a[1],xxx,sizeof(Safe<int>)*3);
>    //Сейчас наши указатели указывают на "мусор"
>    try {
> 	cout << "a[0]=" << a[0] << "\n"
> << flush;
> 	cout << "a[4]=" << a[1] << "\n"
> << flush;
>    } catch(int a)
>    {
> 	cout << "Bad pointer !\n" << flush;
>    }
>    
>    return 0;
>  }
> 
> 

---
>
> Но все операторы придется написать самостоятельно, это
> несложно...
[C++] вариант решения... 23.07.01 10:54  
Автор: XR <eXtremal Research> Статус: The Elderman
<"чистая" ссылка>
> Ну ты и нагородил!
> Вместо того, чтобы использовать "умный" массив,

Это тоже вариант который я кстати обычно использую при работе с МАССИВАМИ...
НО он годится
ТОЛЬКО для массивов...

а вопрос стоял несколько шире...

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

Я кстати в своих реальных программах при в критических случаях использую
гораздо более изощренный контроль :)


А то что я тут как ты говоришь "нагородил"
это легкий ЭКСПРОМПТ из голова (я надеюсь работающий :))


Дляобщегослучая решения данной проблемы иных вариантов не существует ..


>> Это же сплошная чушь.

Не вижу доказателств данного утверждения в виде кода :)

BTW: Давай будем ОТВЕЧАТЬ за слова. OK?


> Ну насмешил - век так не смеялся!
>

Тыб лучше глубже занялся ООД :)



PS: попробуй поймать своим "умным массивом"

Второй вариант, рассмотренный мной ("плохой" указатель)



> > > > > Как в С++ обноружить выход за пределы
> границ
> > > массива и

> > > > > всякие разные плохие укозатели???
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Вот с этим вот КАК ?

> >
> >
> > > Напиши под винду дорогой
> > Но насчет ^^^^^^^^ это к cb :) его главное озадачить в
> > ПРАВИЛЬНОМ направлении ...
> >
> > >
> > > 
> > > int main()
> > > {
> > >   int a[4];
> > >   a[4]=666;
> > > 
> > >   return 0;
> > > }
> > 
> > 
> > > 
> > > 

---
> > > > проверяй указатель на NULL.
> > >
> > > с чего это он вдруг станет NULL?
> > >
> >
> > Если речь идет о C++
> > то ...
> >
> > #include <iostream>
> > template <class T>
> > class Safe
> > {
> > T	  value;
> > int  protect;
> > public: 
> > 
> > Safe<T>(){protect=0x666;}
> > Safe<T>(T& a){protect=0x666;}
> > ~Safe<T>(){protect=0x999;}
> > 
> > T& GetValue()	{return value;}
> > 
> > Safe<T>& operator = (const T a) throw(T)
> >  {
> >   if(protect!=0x666) throw a;
> >   value=a;
> >   return *this;
> >  }
> > 
> > friend ostream& operator << (ostream& os,
> > Safe<T>& a) throw(T)
> >  {
> >   if(a.protect!=0x666) throw a.value;
> >   os << a.value;
> >   return os; 
> >  }
> > };
> > 
> > int main()
> >  {
> >	Safe<int> a[4];
> >	int b=2;
> >	// Проверяем на выход за границу массива   
> >	try {
> >	a[0]=1;
> >	cout << "a[0]=" << a[0] << "\n"
> > << flush;
> >	a[1]=b;
> >	cout << "a[1]=" << a[1] << "\n"
> > << flush;
> >	a[4]=666;
> >	cout << "a[4]=" << a[4] << "\n"
> > << flush;
> >	} catch(int a)
> >	{
> >	cout << "Bad index !\n" << flush;
> >	}


Вот это вот как ты предлагаешь ловить ?

> >	char xxx[40];
> >	memcpy(&a[1],xxx,sizeof(Safe<int>)*3);
> >	//Сейчас наши указатели указывают на "мусор"
> >	try {
> >	cout << "a[0]=" << a[0] << "\n"
> > << flush;
> >	cout << "a[4]=" << a[1] << "\n"
> > << flush;
> >	} catch(int a)
> >	{
> >	cout << "Bad pointer !\n" << flush;
> >	}
> >	
> >	return 0;
> >  }
> > 
> > 

---
> >
> > Но все операторы придется написать самостоятельно, это
> > несложно...


PS: часть проблем кстати снимается использованием STL
[C++] Вариант неплох, но ?! 23.07.01 12:32  
Автор: no name Статус: Незарегистрированный пользователь
<"чистая" ссылка>
>> if(protect!=0x666) throw a;

Скажи честно ты на 100% уверен что в куче ненайдется значения 0x666 ???
Если так, то ты ОПТИМИСТ, а если считаешь, что вероятность этого пренебрежимо мала, то почитай законы Мерфи :)

По моему для массивов лучше поступать так как предложил <kabanchik>,
то есть в твоем случае перегрузить оператор [] и проверять индекс.

>>Дляобщегослучая решения данной проблемы иных вариантов не >>существует ..

Я бы выразился конкретнее: общего решения для данноя проблеммы вообще не существует, по крайней мере в языке C.







[C++] Вариант неплох, но ?! 23.07.01 14:07  
Автор: XR <eXtremal Research> Статус: The Elderman
Отредактировано 23.07.01 19:36  Количество правок: 1
<"чистая" ссылка>
> >> if(protect!=0x666) throw a;
>
> Скажи честно ты на 100% уверен что в куче ненайдется
> значения 0x666 ???
> Если так, то ты ОПТИМИСТ, а если считаешь, что вероятность
> этого пренебрежимо мала, то почитай законы Мерфи :)

Если следовать законам сего достойного человека - криптография это вообще
лженаука :))
BTW: Я не оптимист я практик :)
>

PS: Это был _учебный пример_ :) ... из головы

Вот самый простойреальныйкусок кода:

template<class T>
class SObj : private Locker,
public T
{
static const char idPlace;
const char* ID;
....
SObj() {ID=&idPlace}

....

int isObjValid() {
if(ID == &idPlace) return 1;
else return 0;
....
};

template <class T>
const char SObj<T>::idPlace='y';

А есть еще и более экстремистские варианты со 128-битовыми сигнатурами


> По моему для массивов лучше поступать так как предложил
> <kabanchik>,
> то есть в твоем случае перегрузить оператор [] и проверять
> индекс.

Если речь идет о массиве то да.

>
> >>Дляобщегослучая решения данной проблемы иных
> вариантов не >>существует ..
>
> Я бы выразился конкретнее: общего решения для данноя
> проблеммы вообще не существует, по крайней мере в языке C.
>

ну я вроде бы показывал решение для C++ :)
Его как раз на такие задачи о затачивали ....


насчет C тоже можно подумать - вот только я на чистом Ц уже лет 7 как не пишу :)
>
>
>
>
>
>
>
[C++] Вариант неплох, но ?! 23.07.01 16:08  
Автор: c0x@mail.ru Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Ну ты опять нагородил, с чего это ты взял, что твой код будет работать корректно, если например по некоторым неизвестным причинам ( аппаратный сбой, запись другим куском кода значения не по тому адресу, etc... ), значение this из "хорошего" станет "не очень", и твое творение:

> > >> if(protect!=0x666) throw a;

или что тоже самое:

> if(ID == &idPlace) return 1;

или твои хваленые 128-ми битные сигнатуры которые еще считать надо на лету ;)

будет постоянно генерировать аппаратное исключение - доступ по несуществующему физическому адресу?

Лучше уж тогда если имеем дело с массивом, а на практике это чаще всего, то перегружаем оператор [ ] и все дела. Даже один объект можно представить как массив из одного элемента. Или написать класс "умного" указателя с перегрузкой оператора доступа ->.

А вот насчет аппаратных сбоев и не только есть такие замечательные апишные ф-ии в вин32:
IsBadCodePtr
IsBadReadPtr
IsBadWritePtr
[C++] Вариант неплох, но ?! 23.07.01 17:27  
Автор: XR <eXtremal Research> Статус: The Elderman
<"чистая" ссылка>
> Ну ты опять нагородил, с чего это ты взял, что твой код
> будет работать корректно, если например по некоторым
> неизвестным причинам ( аппаратный сбой,

Получишь трап ядра - и все умрет ..

> запись другим

кода ? у тебя .text сегмент writable ? :) ню-ню

> куском кода значения не по тому адресу, etc... ), значение
> this из "хорошего" станет "не очень", и твое творение:

RTFM про статические члены класса.

>
> > > >> if(protect!=0x666) throw a;
>
> или что тоже самое:
>
> > if(ID == &idPlace) return 1;
>
> или твои хваленые 128-ми битные сигнатуры которые еще
> считать надо на лету ;)

Сигнатуры это не hash-и их надо не считать а хранить ...RTFM

> будет постоянно генерировать аппаратное исключение - доступ
> по несуществующему физическому адресу?
>
> Лучше уж тогда если имеем дело с массивом, а на практике
> это чаще всего, то перегружаем оператор [ ] и все дела.

Ага уже операторы таки перегружаем ... уже лучше :)

> Даже один объект можно представить как массив из одного
> элемента. Или написать класс "умного" указателя с
> перегрузкой оператора доступа ->.
>

Ну давай напиши, а я посмотрю чем это будет отличатсяидеологическиот моего
варианта


я еще понимаю если бы речь шла о namespace то разговор бы может быть получился
а так это пустая брехня, извини, ничего личного... :)


> А вот насчет аппаратных сбоев и не только есть такие
> замечательные апишные ф-ии в вин32:
> IsBadCodePtr
> IsBadReadPtr
> IsBadWritePtr
И ЧТО ты этим проверишь :)) RTFM однако про защиту памяти ...
Извини что начинаю переходить на твой язык но вот это как раз БРЕД :)

Ты вообще C++ изучал ? Непохоже :)

PS: в настоящий момент я в 90% случаев пишу не под Win32
[C++] Вариант неплох, но ?! 23.07.01 18:26  
Автор: c0x@mail.ru Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> Получишь трап ядра - и все умрет ..
наивный ты мой... 8))) Я же сказал - аппаратный сбой. Бывает иногда, знаете ли, батенька, на дешевой китайской памяти и разогнанном камне...

...
> кода ? у тебя .text сегмент writable ? :) ню-ню
> RTFM про статические члены класса.
ну что еще и как доказывать человеку, у которого this - статический Ж8-0, и соответственно this->ID тоже ? Ну тогда ты явно забыл "char* ID;" объявить как static или сам объект сделать static, но в этом случае грош цена всем этим твоим извращениям...

...
> Ага уже операторы таки перегружаем ... уже лучше :)
>
а без этого никак, если делать wrapper для этих вещей. И не уже, а очччень давно и не менее успешно.

...
> а так это пустая брехня, извини, ничего личного... :)
8)))
ну я не мембер, и не получаю от dl бабки как ты за "разводку" ламеров на этой борде, и рабочий код постить - нет, пусть сами думают.

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

...
> И ЧТО ты этим проверишь :)) RTFM однако про защиту памяти
> ...
> Извини что начинаю переходить на твой язык но вот это как
> раз БРЕД :)
>
> Ты вообще C++ изучал ? Непохоже :)
ну если ты у нас такой гуру, посмотри повнимательней на свой код, дружок. Тебя не тошнит?

>
> PS: в настоящий момент я в 90% случаев пишу не под Win32
ну я знаю что ты юниксоид, и все эти проблемы с демонами думаю от тех кто разделяет с тобой стиль программирования.

Почти ничего личного,
c0x

ЗЫ:
Я вобщемто ничего не имею против сигнатур, даже m$ это применяет в своей malloc библиотеке (debug) - и не только m$.

ЗЗЫ: в настоящий момент я тоже в 90% случаев пишу не только не под Win32, но даже не под IA.
[C++] Вариант неплох, но ?! 23.07.01 19:33  
Автор: XR <eXtremal Research> Статус: The Elderman
<"чистая" ссылка>
> > Получишь трап ядра - и все умрет ..
> наивный ты мой... 8))) Я же сказал - аппаратный сбой.
> Бывает иногда, знаете ли, батенька, на дешевой китайской
> памяти и разогнанном камне...
>
А ты попробуй дернуть слегка либо камень либо димку "на ходу" :)
Очень знаешь ли поучительно ... разумеется все умрет но в ряде
случаев ядро ловит этот трап а уж битую память это как 2 байта

> ...
> > кода ? у тебя .text сегмент writable ? :) ню-ню
> > RTFM про статические члены класса.
> ну что еще и как доказывать человеку, у которого this -
> статический Ж8-0, и соответственно this->ID тоже ? Ну
> тогда ты явно забыл "char* ID;" объявить как static или сам
> объект сделать static, но в этом случае грош цена всем этим
> твоим извращениям...
>

Ты код то смотрел ? :)

Покажешь работающий код - прибивающий сей механизм бум говорить
нет - не будет разговор

там результатов 2
либо ловим сигнал ядра (указатель смотрит в защищенную область) либо если указатель смотрит в нашу память то ловим наш трап ...


> ...
> > Ага уже операторы таки перегружаем ... уже лучше :)
> >
> а без этого никак, если делать wrapper для этих вещей. И не
> уже, а очччень давно и не менее успешно.
>

Молодец токо зачем стоко пальцев то сразу ?
Я как бы тоже не первый год это делаю и даже не десятый уже :)

> ...
> > а так это пустая брехня, извини, ничего личного... :)
> 8)))
> ну я не мембер, и не получаю от dl бабки как ты за
> "разводку" ламеров на этой борде, и рабочий код постить -
> нет, пусть сами думают.

Все так сурьезно ? :)

за базар про бабки это ты перед dl объяснятся бушь, лады ?

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

Ага - и как ты отличишь указатель на Calss1 от Class2 :)))

ЗЫЖ: а страница на объект тебя не ломет ?
> ...
> > И ЧТО ты этим проверишь :)) RTFM однако про защиту
> памяти
> > ...
> > Извини что начинаю переходить на твой язык но вот это
> как
> > раз БРЕД :)
> >
> > Ты вообще C++ изучал ? Непохоже :)

> ну если ты у нас такой гуру, посмотри повнимательней на
> свой код, дружок. Тебя не тошнит?

Я пока не видел твоего :)

Короче - кончай собачится есть конкретные претензии к стиль кодирования
мыло вверху

Извиняй что я сегодня нервный ...ну сорвался я сегодня :)

> ЗЗЫ: в настоящий момент я тоже в 90% случаев пишу не только
> не под Win32, но даже не под IA.

а для ++ есть БОЛЬШАЯ разница между IA32 и к примеру SPARC ? :)
[C++] Вариант неплох, но ?! 23.07.01 20:17  
Автор: c0x@mail.ru Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> А ты попробуй дернуть слегка либо камень либо димку "на
> ходу" :)
> Очень знаешь ли поучительно ... разумеется все умрет но в
> ряде
> случаев ядро ловит этот трап а уж битую память это как 2
> байта
да кто тут говорит о дергании - достаточно повышенной солнечной радиации в этом месяце и жаркой погоды, чтобы изменить пару бит по случайному адресу (опять же пресловутые законы Мерфи). Думаешь зря чтоли существуют соответствующие технологии (RAM ECC, SFT level XXX, etc...)

> Покажешь работающий код - прибивающий сей механизм бум
> говорить
> нет - не будет разговор
будет тебе код.

> > > а так это пустая брехня, извини, ничего
> личного... :)
> > 8)))
> > ну я не мембер, и не получаю от dl бабки как ты за
> > "разводку" ламеров на этой борде, и рабочий код
> постить -
> > нет, пусть сами думают.
>
> Все так сурьезно ? :)
>
> за базар про бабки это ты перед dl объяснятся бушь, лады ?
ну пусть и виртуальные (в виде рейтинга) но имеешь ведь !?? Или пиво !??

> > ...
> > > > IsBadCodePtr
> > > > IsBadReadPtr
> > > > IsBadWritePtr
> > достаточно и этого - умный схватит идею в комплексе.
> >
>
> Ага - и как ты отличишь указатель на Calss1 от Class2 :)))
а это забота компилятора, а не моя. А тем кто играется в игры class->void->class надо руки отшибать, ИМХО!

>
> ЗЫЖ: а страница на объект тебя не ломет ?
какая страница, памяти чтоли?

> Я пока не видел твоего :)
>

// file "ptrtest.h"

template <class T>
class safeptr
{
T* realptr;

public:
safeptr(): realptr(NULL) {};
safeptr(T* ptr): realptr(ptr) {};

operator T*() { if( IsBadReadPtr(this, sizeof(*this))|IsBadReadPtr(realptr, sizeof(T))|IsBadWritePtr(realptr, sizeof(T)) ) throw (this);
return realptr;
};


T* operator ->() { if( IsBadReadPtr(this, sizeof(*this))|IsBadReadPtr(realptr, sizeof(T))|IsBadWritePtr(realptr, sizeof(T)) ) throw (this);
return realptr;
};

// ну и т.д. IsBadWritePtr(realptr, sizeof(T)) - опционально, есесьно если это указатель на const - то не надо.
};

// end file "ptrtest.h"


// file "ptrtest.cpp"

#include <windows.h>
#include "ptrtest.h"

typedef struct {
int a;
char b;
} somestruct;


void main(void)
{
safeptr<somestruct> p = new somestruct;

try {
p->a = 0x0a;
p->b = 'B';
}

catch (...) {
MessageBox(0, "memory access error", "XCEPTION", MB_ICONSTOP|MB_OK);
}
}

// end file "ptrtest.cpp"

вот и попробуй под отладчиком поменять значение realptr

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

А тем, кого тянет на арифметику с указателями через заднюю калитку, надо просто руки отшибать. Или защищаться от них перегрузкой соответствующих операторов которые либо будут ничего не делать либо говорить что типа ты дурак и руки проч и в таком духе.

Короче, реальных указателей и массивов в программе не должно бытьВООБЩЕ- это и есть штиль программирования без глюков, ИМХО! Ну, кроме быть может частей кода тесно работающего с системными вызовами. Но там - это уже забота ядра.
[C++] Вариант неплох, но ?! 24.07.01 11:08  
Автор: XR <eXtremal Research> Статус: The Elderman
Отредактировано 24.07.01 11:32  Количество правок: 1
<"чистая" ссылка>
> солнечной радиации в этом месяце и жаркой погоды, чтобы
> изменить пару бит по случайному адресу (опять же
> пресловутые законы Мерфи). Думаешь зря чтоли существуют
> соответствующие технологии (RAM ECC, SFT level XXX, etc...)

Эт офтопик в контексте нашего с тобой спора :)


> > Покажешь работающий код - прибивающий сей механизм бум
> > говорить
> > нет - не будет разговор
> будет тебе код.

Вот это другой разговор :)

> ну пусть и виртуальные (в виде рейтинга) но имеешь ведь !??

????

2dl: не уберешь меня из рейтинга совсем ?


> Или пиво !??

Если б мне за это пиво ставили я бы года 3 назад спился бы уже :))))

> > Ага - и как ты отличишь указатель на Calss1 от Class2
> :)))
> а это забота компилятора, а не моя. А тем кто играется в
> игры class->void->class надо руки отшибать, ИМХО!

Тут не все так просто ... мне сплошь и рядом приходится с этим сталкиваться
например при передаче объектов по сетке либо при скармливании указателя
на объект функциям типа pthread_create(...) etc.

[код скипнут]

> вот и попробуй под отладчиком поменять значение realptr

Зачем отладчиком то ?

int a[10]
memcpy(p,a,sizeof(p)) вполне годится :) и все твои is* идут лесом :)


я говорил вот о чем:
char       a[10];
Safe<char> b[10];

try {
for(int i=0; i<15;i++)
    b = a;    
}catch(...){printf("Bad object.\n");}

---

то есть защита целосности самого объекта


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

Вопросы дизайна это вопросы вкуса ... я например итераторы ненавижу :)

>


> Короче, реальных указателей и массивов в программе не
> должно бытьВООБЩЕ- это и есть штиль программирования
> без глюков, ИМХО! Ну, кроме быть может частей кода тесно
> работающего с системными вызовами. Но там - это уже забота
> ядра.

Ну Java так и делает. Вообще вопрость стиля это не вопрос ImHO ...


PS: Извини за вчерашнюю резкость, просто история с Димкой меня напрочь выбила из
колеи :(
[C++] Вариант неплох, но ?! 24.07.01 12:08  
Автор: c0x@mail.ru Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> > игры class->void->class надо руки отшибать,
> ИМХО!
>
> Тут не все так просто ... мне сплошь и рядом приходится с
> этим сталкиваться
> например при передаче объектов по сетке либо при
> скармливании указателя
> на объект функциям типа pthread_create(...) etc.
дак ты на одном конце структуру или объединение закидываешь в сеть а на другом это же самое ловишь - какой смысл говорить ф-ии что это не верблюд допустим а жираф? нафига такие фокусы?

>
> [код скипнут]
>
> > вот и попробуй под отладчиком поменять значение
> realptr
>
> Зачем отладчиком то ?
>
> int a[10]
> memcpy(p,a,sizeof(p)) вполне годится :) и все твои is* идут
> лесом :)
>
>
> я говорил вот о чем:
>
> char	   a[10];
> Safe<char> b[10];
> 
> try {
> for(int i=0; i<15;i++)
>     b = a;    
> }catch(...){printf("Bad object.\n");}
> 

---
>
> то есть защита целосности самого объекта
>
ну ты этими мет0дами объект на 100% защитить все равно не сможешь - зачем огород городить и память (процессорное время) тратить? ты смог только определить что А это не В, даже если бы это был pure C я вряд ли бы согласился, но не проще ли и безопаснее реализовать это семантически ведь ты позиционируешь как решение для C++? Ты же все равно перегрузил оператор = так перегрузи его с другой сигнатурой для А и делай необходимые преобразования. Или кидай исключения - по вкусу. А?

>
> Вопросы дизайна это вопросы вкуса ... я например итераторы
> ненавижу :)
ну о вкусах принято не спорить ;)

> Ну Java так и делает. Вообще вопрость стиля это не вопрос
> ImHO ...
>
Ну-ну. Есть тутачки на борде уникумы рожающие кривыми руками/мозгами ТАКОЙ код, что слеза наворачивается. А потом они подрастают и начинают работать в фирмах, клепать для них как пельмени свое убожество. А страдают пользователи.


>
> PS: Извини за вчерашнюю резкость, просто история с Димкой
> меня напрочь выбила из
> колеи :(
это меня не касается
[C++] Вариант неплох, но ?! 24.07.01 13:54  
Автор: XR <eXtremal Research> Статус: The Elderman
Отредактировано 24.07.01 13:55  Количество правок: 1
<"чистая" ссылка>
> дак ты на одном конце структуру или объединение закидываешь
> в сеть а на другом это же самое ловишь - какой смысл
> говорить ф-ии что это не верблюд допустим а жираф? нафига
> такие фокусы?

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

PS: посмотри спецификацию RPC и ужаснись какие там оверхеды на приведение/проверку типов при этом сии спецификации покрывают полько
встроенные типы.

> ну ты этими мет0дами объект на 100% защитить все равно не
> сможешь - зачем огород городить и память (процессорное
> время) тратить?

Не вполне хватает 99,9% :)
BTW: При более внимательном рассмотрении ты увидишь что сигнатура тратит
не больше процессорного времени нежели тот же массив с проверкой индекса ...
вот место под сигнатуру да, тратится ... того это сейчас малоактуально

ты смог только определить что А это не В,
> даже если бы это был pure C я вряд ли бы согласился, но не
> проще ли и безопаснее реализовать это семантически ведь ты
> позиционируешь как решение для C++?

Я уже выше показал в каких случаяхсематническиэто не получается
или ты считаешь что надо на каждую внешнюю библиотеку писать свою обвязку ?
Так в этой самой обвязке семантика тоже идет лесом и приведение к void*
будет через строчку.

> >
> > Вопросы дизайна это вопросы вкуса ... я например
> итераторы
> > ненавижу :)
> ну о вкусах принято не спорить ;)

А вы в 10 последних реплаях чем были заняты ? :)

>
> > Ну Java так и делает. Вообще вопрость стиля это не
> вопрос
> > ImHO ...
> >
> Ну-ну. Есть тутачки на борде уникумы рожающие кривыми
> руками/мозгами ТАКОЙ код, что слеза наворачивается. А потом
> они подрастают и начинают работать в фирмах, клепать для
> них как пельмени свое убожество. А страдают пользователи.

Вы путаете стиль с дизайном :)

>
> >
> > PS: Извини за вчерашнюю резкость, просто история с
> Димкой
> > меня напрочь выбила из
> > колеи :(
> это меня не касается

А вот ЭТО ты ImHO зря ... вспомни русскую пословицу насчет заречений ..
1  |  2  |  3  |  4 >>  »  




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


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