Проверка, что память была инициализирована в C
Вы можете поместить данные в файл mdb, используя ado, и обойти ограничение в 256 столбцов. Однако использование UDF для извлечения данных непосредственно из любого внешнего источника данных будет очень медленным, если у вас их больше, чем несколько. Я бы создал класс для хранения данных с помощью метода load, вызываемого при открытии электронной таблицы, и чтобы ваши функции запрашивали объект. Таким образом, ваш метод загрузки принимает ваш CSV в качестве потока данных и заполняет дисконнектированный набор записей ado, определенный как статическую переменную, а затем вы определяете метод getdata, который возвращает желаемое значение на основе переданных ему параметров.
6 ответов
Ваша переменная контекста является, вероятно, в данный момент некоторым указателем на выделенную память. Вместо этого сделайте это маркером или дескриптором, который может быть явно проверен. Каждый раз, когда контекст инициализируется, Вы возвращаете новый маркер (не фактический объект контекста) и хранилище что маркер во внутреннем списке. Затем когда клиент дает Вам контекст позже, Вы проверяете, что это допустимо путем взгляда в списке. Если это, маркер может затем преобразовываться в фактический контекст и использоваться, иначе ошибка возвращается.
typedef Context long;
typedef std::map<Context, InternalContext> Contexts;
Contexts _contexts;
Context nextContext()
{
static Context next=0;
return next++;
}
Context initialise()
{
Context c=nextContext();
_contexts.insert(make_pair(c, new InternalContext));
return c;
}
void doSomethingWithContext(Context c)
{
Contexts::iterator it=_ _contexts.find(c);
if (it==_contexts.end())
throw "invalid context";
// otherwise do stuff with the valid context variable
InternalContext *internalContext=*it.second;
}
С этим методом нет никакого риска недопустимого доступа к памяти, поскольку Вы будете только правильно использовать допустимые ссылки контекста.
Лучшее решение, я думаю, добавляют, создают ()/, удаляют (), функции к Вашему API и использованию создают, чтобы выделить и инициализировать структуру. Можно поместить подпись в начале структуры, чтобы проверить, что указатель, с которым Вы передаетесь точки памяти, выделенной, создает (), и использование удаляют () для перезаписи подписи (или весь буфер) прежде, чем освободить память.
Вы не можете на самом деле избежать ложных положительных сторон в C, потому что вызывающая сторона malloc'd память, которая, "оказалось", запускалась с Вашей подписи; но сделайте Вас подписью довольно долго (скажите, что 8 байтов), и разногласия являются низкими. При вынимании выделения из рук вызывающей стороны путем обеспечения создавания () функция будет иметь большое значение, все же.
И, да, Ваш самый большой риск состоит в том, что инициализированный буфер является free'd без использования, удаляют (), и последующий malloc, оказывается, снова использует тот блок памяти.
Вы могли определить новый вызов API, который берет неинициализированную память и инициализирует ее любым способом, которым Вам нужно. Затем часть клиента, который API - то, что клиент должен вызвать функцию инициализации контекста, в других отношениях неопределенное поведение, закончится.
Посмотрите на статью Матового епископа на Робастном программировании. Использование билетов или маркеров (подобный дескрипторам файлов в некотором отношении, но также и включая данный случай - число, используемое однажды), позволяет Ваш код библиотеки, гарантируют, что маркер, который это использует, допустим. На самом деле Вы выделяете структуру данных от имени пользователя и пасуете назад пользователю билет, который должен быть предоставлен для каждого вызова к API, который Вы определяете.
У меня есть некоторый код, базирующийся тесно на той системе. Заголовок включает комментарии:
/*
** Based on the tickets in qlib.c by Matt Bishop (bishop@ucdavis.edu) in
** Robust Programming. Google terms: Bishop Robust Nonce.
** http://nob.cs.ucdavis.edu/~bishop/secprog/robust.pdf
** http://nob.cs.ucdavis.edu/classes/ecs153-1998-04/robust.html
*/
Я также создал основанную на арене систему выделения памяти с помощью билетов для идентификации различных арен.
Для обхождения проблемы ячейки памяти предыдущего снова используемого контекста Вы, в дополнение к освобождению контекста, могли сбросить его и удалить "волшебное" число, предположив, конечно, что пользователь освобождает контекст с помощью API. Тот путь, когда система возвратит тот же самый блок памяти для следующего запроса контекста, проверка магического числа, перестанет работать.
посмотрите то, что Ваша система делает с uninitialzed памятью. m$ делает: Неинициализированные блоки памяти в VC ++