Тут размещают свои топики новички в С/С++.

_DEN_
как возможность переполнения буфера

 

Nouzui

Напомню, что в моем случае first - LPWSTR. И такой прием кончается следующим:

error C2664: 'wcscpy' : cannot convert parameter 1 from 'LPCWSTR' to 'wchar_t *'

 

IceFire
wcscpy((wchar_t*)first, buffer);

 

Great

гы, спасибо ) я че-то затупил ))

 

IceFire
почему у тебя first типа LPCWSTR, а не просто LPWSTR?

 

Great

Это же текст. Или ты туда Войну и мир засунуть решил?

 

_DEN_
а кто знает... ))
раньше тоже смеялись, пока не начали эксплуатировать уязвимости в библиотеках обработки bmp %(

 

Nouzui

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

 

_DEN_
ну так на случай таких криворуких кодеров и есть wcsncpy, чтобы вдруг не слетал стек, если кодер случайно выделил в стеке буфер для строки

 

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

 

Nouzui

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

 

Nouzui

http://www.yandex.ru/yandsearch?rpt=rad&text=STL+%EA%EE%ED%F2%E5%E9%ED%E5%F0%FB

Значит ты программируешь на C, а не на C++.

Great

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

 

зато от переполнения иногда спасает. хотя никто не спорит, что писать надо правильно

 

Ахха. Не так давно товарищу предложили представить составляющую цвета как объект (три объекта на пиксел). И описать ими картинку. Он долго ждал, пока завершится её создание…

 

IceStudent

Ну так это опять от неправильного понимания ООП)) Класс - это функциональная единица, а не концептуальный тип. Делать свой класс на каждый цвет - вкорне неверное понимание ООП. Да и пиксель это простой аггрегат, а не функциональная единица, и делание его классом так же попахивает ламеризмом.

Вот такое представление будет работать практически так же как и прямая работа с битмапом:

Код (Text):

1. struct Pixel
2. {
3.     typedef unsigned char Component;
4.  
5.     Component m_Red;
6.     Component m_Green;
7.     Component m_Blue;
8. };
9.  
10. typedef std::vector<Pixel> Bitmap;

Надо пользоваться нормальными компиляторами и не забывать включать Release

 

ну лан, а что это дает?

зы: насчет C ты, пожалуй, прав

 

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

 

я имел в виду, как это связано с переполнением буфера:

 

Nouzui

Память в контейнерах выделяется не на стеке. Поэтому не более чем Access Violation или Bad Alloc.

 

гм.. строковые буферы тоже можно выделять не в стеке, только панацея ли это? Про стек тоже раньше думали - ну перетрет адрес возврата, ну вернется управление не туда, ну и закончится это ексепшеном.. а мысль о том, что это может использоваться для передачи управления коду, размещенному в том же самом стековом буфере, вроде, выглядела достаточно смешно - откуда атакующий может знать текущее значение ESP, чтобы определить, каким именно значением нужно перетереть адрес возврата, ведь текущая позиция в стеке зависит от слишком большого числа факторов, включая версию оси, версию продукта, момент атаки итд..
и ниче, эксплоиты пошли волной. Думаешь, если память переезжается не в стеке, то этим невозможно будет воспользоваться?