Как известно, в дебаге различные неиспользуемые или неинициализированные участки памяти заполняются характерными значениями
Например неинициализированные переменные хранят обычно СССССС
А удалённая память хранит чсто fefefe (или что-то вроде того).
А вот где можно точно узнать каким значениям какой статус соответствует ?
Это можно задавать в опциях линковщика/компилятора ?

vilgelm wrote:

> Как известно, в дебаге различные неиспользуемые или неинициализированные участки памяти заполняются характерными значениями
> Например неинициализированные переменные хранят обычно СССССС

gcc не заполняет.

--
Maxim Yegorushkin

Здравствуйте, vilgelm, Вы писали:

V>Как известно, в дебаге различные неиспользуемые или неинициализированные участки памяти заполняются характерными значениями
V>Например неинициализированные переменные хранят обычно СССССС
V>А удалённая память хранит чсто fefefe (или что-то вроде того).
V>А вот где можно точно узнать каким значениям какой статус соответствует ?
V>Это можно задавать в опциях линковщика/компилятора ?

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

Здравствуйте, MaximE, Вы писали:

ME>vilgelm wrote:

>> Как известно, в дебаге различные неиспользуемые или неинициализированные участки памяти заполняются характерными значениями
>> Например неинициализированные переменные хранят обычно СССССС

ME>gcc не заполняет.
Это личный половой вопрос gcc.
Компиллер майкросовт заполняет чем-то там. У них это как-то документированно ?
ME>--
ME>Maxim Yegorushkin

Здравствуйте, Glоbus, Вы писали:

G>Здравствуйте, vilgelm, Вы писали:

V>>Как известно, в дебаге различные неиспользуемые или неинициализированные участки памяти заполняются характерными значениями
V>>Например неинициализированные переменные хранят обычно СССССС
V>>А удалённая память хранит чсто fefefe (или что-то вроде того).
V>>А вот где можно точно узнать каким значениям какой статус соответствует ?
V>>Это можно задавать в опциях линковщика/компилятора ?

G>А зачем тебе это надо? Попытка проверять значения, хранящиеся в неинициализированных переменных или работата с освобожденной памятью вообще на мой взгляд является логической ошибкой. Так что я бы на это не подвазявался на твоем месте. По идее там может хранится все что угодно, а дебаговые значения — это просто частнрый случай этого "чего угодно".

Да ежу понятно что ненадо проверять.
Мне нужно знать в отладочных целях, я на память смотрю, и что б узнать что с ней произошло и понять в каком направлении копать дальше. Иногда бывает полезно.
Вот например увидев значения 0xссссссс в переменной сразу знаешь что она неинициализирована.
Я примерно об этом.

Здравствуйте, vilgelm, Вы писали:

>>> Как известно, в дебаге различные неиспользуемые или неинициализированные участки памяти заполняются характерными значениями
>>> Например неинициализированные переменные хранят обычно СССССС

ME>>gcc не заполняет.
V>Это личный половой вопрос gcc.
V>Компиллер майкросовт заполняет чем-то там. У них это как-то документированно ?
ME>>--
ME>>Maxim Yegorushkin

В release не заполняет и MS. И расчитывать на то, что там находится не стоит. тем не менее поиск показал:

Table 1. Potential patterns
Pattern Description
0xFDFDFDFD No man's land (normally outside of a process)
0xDDDDDDDD Freed memory
0xCDCDCDCD Uninitialized (global)
0xCCCCCCCC Uninitialized locals (on the stack)

vilgelm wrote:

>>> Как известно, в дебаге различные неиспользуемые или неинициализированные участки памяти заполняются характерными значениями
>>> Например неинициализированные переменные хранят обычно СССССС
>
> ME>gcc не заполняет.
> Это личный половой вопрос gcc.

Это я к тому, что "Как известно, в дебаге"... Вообще, вопрос имеет малое отношение к С++.

--
Maxim Yegorushkin

Здравствуйте, vilgelm, Вы писали:

V>Да ежу понятно что ненадо проверять.
V>Мне нужно знать в отладочных целях, я на память смотрю, и что б узнать что с ней произошло и понять в каком направлении копать дальше. Иногда бывает полезно.
V>Вот например увидев значения 0xссссссс в переменной сразу знаешь что она неинициализирована.
V>Я примерно об этом.

Whether or not you use MFC, take a hint from MFC's DEBUG_NEW macro. When memory is first allocated, each byte is initialized to 0xCD. Before memory is deleted, it is set to 0xDD. So, if you ever see an object whose memory is mysteriously all set to “CDCDCD” you know that it's an uninitialized object, and if the memory is all “DDDDDD” you know it's a deleted object. This is accomplished with the DEBUG_NEW macro, which you can activate in your project with the following code:
#define new DEBUG_NEW

Здравствуйте, vilgelm, Вы писали:

V>Например неинициализированные переменные хранят обычно СССССС
дело в том что 0xCC соответсвует команде "int 3", которая вызывает брекпойнт в отладчике.

V>А удалённая память хранит чсто fefefe (или что-то вроде того).
Это только в отладочной версии Runtime library.

V>Это можно задавать в опциях линковщика/компилятора ?
Нет.

Здравствуйте, 0xDEADBEEF, Вы писали:

V>>Например неинициализированные переменные хранят обычно СССССС
DEA>дело в том что 0xCC соответсвует команде "int 3", которая вызывает брекпойнт в отладчике.

почему только в отладчике? и без него!

V>>Это можно задавать в опциях линковщика/компилятора ?
DEA>Нет.

вроде опция компилятора /GZ управляет этим для MS и для стековых переменных

Здравствуйте, 0xDEADBEEF, Вы писали:

V>>Это можно задавать в опциях линковщика/компилятора ?
DEA>Нет.

BoundsChecker позволяет это частично менять.
Есть у них так называемый “poison” patterns

V>А вот где можно точно узнать каким значениям какой статус соответствует ?
V>Это можно задавать в опциях линковщика/компилятора ?

Вот нарыл:

Это делает Microsoft Visual C++ Runtime library (см. crtdbg.h, DbgHeap.c в исходниках CRT и др.)

0xCD, 0xCDCDCDCD — New objects. New objects are filled with 0xCD when they are allocated.
0xFD, 0xFDFDFDFD — No-man's land memory. Extra bytes that belong to the internal block allocated, but not the block you requested. They are placed before and after requested blocks and used for data bound checking.
0xDD, 0xDDDDDDDD — Freed blocks. The freed blocks kept unused in the debug heap's linked list when the _CRTDBG_DELAY_FREE_MEM_DF flag is set are currently filled with 0xDD. Although in some cases you won't see magic 0xDDDDDDDD value, as it will be overwritten by another debug function (e.g. 0xFEEEFEEE for HeapFree).

т.е. когда ты делаешь malloc, память заполняется 0xCD и ограничивается дополнительными 0xFD (для проверки выхода за границы массивов). После удаления она содержит 0xDD.

Это делает компилятор Visual C++:

0xCC, 0xCCCCCCCC — The /GX Microsoft Visual C++ compiler option initialises all local variables not explicitly initialised by the program. It fills all memory used by these variables with 0xCC, 0xCCCCCCCC.

Т.е. всё, что создаётся на стеке (или конструкторами?), заполняется 0xCC.

Это делает Windows API (HeapAlloc и пр.):

0xABABABAB — Memory following a block allocated by LocalAlloc().
0xBAADF00D — "Bad Food". This is memory allocated via LocalAlloc( LMEM_FIXED, ... ). It is memory that has been allocated but not yet written to.
0xFEEEFEEE — OS fill heap memory, which was marked for usage, but wasn't allocated by HeapAlloc() or LocalAlloc(). Or that memory just has been freed by HeapFree().

В общем, неинициализированная память содержит 0xCC или 0xCD. Иногда нули (при соотв. опции HeapAlloc). Удалённая память содержит 0xDD или 0xFE, или 0xFeeeFeee (выровнена по DWORD). "No man's land" содержит 0xFD, 0xAB, 0xBAADF00D, 0xBAADBEEF и пр

Может кто-нибудь найдет время и проверит всевозможные случаи для VC++