Использование неинициализированного значения размера 8 Valgrind - PullRequest
0 голосов
/ 29 июня 2018

Я получаю

==56903== Use of uninitialised value of size 8
==56903==    at 0x1000361D1: checkMSB (in ./UnittestCSA)
==56903==    by 0x10003732A: S_derive_k1_k2 (in ./UnittestCSA)

Код выглядит следующим образом:

int32_t checkMSB(uint8_t *pKey){
    int8_t msb = 0;
    int32_t ret = 0;
    msb = 1 << (8 - 1);
    /* Perform bitwise AND with msb and num */
    if(pKey[0] & msb){
        ret = 1;
    } else {
        ret = 0;
    }
    return ret;
}

Не уверен, что является причиной проблемы.

Если это

#define BITS (sizeof(int8_t) * 8)

изменено на это

#define BITS (sizeof(int) * 8)

это не жалуется. У меня есть #include <stdint.h> заголовочный файл.

UPDATE

uint8_t localK1[BLOCKSIZE];
for(index = 0; index < inputLen; index++){
    localK1[index] = pInputText[index];
}

result = checkMSB(localK1);

1 Ответ

0 голосов
/ 29 июня 2018

Ваша функция checkMSB объявляет только две локальные переменные и один параметр функции. Обе переменные имеют инициализаторы, и параметр (указатель) получит значение в результате вызова функции, предполагая, что правильный прототип для него находится в области видимости в точке вызова. Таким образом, ни один из них не используется неинициализированным.

Единственными другими данными, которые используются (не считая констант), являются те, которые указывают на аргументом pKey. Из них ваш код использует pKey[0]. То, что Valgrind сообщает о проблеме, подтверждает вывод о том, что это данные, на которые он жалуется: служба memcheck по умолчанию, которую выполняет valgrind, следит за динамически распределенной памятью, и это единственное, что может быть выделено динамически.

То, что ошибка исчезает, когда вы изменяете определение BITS, может быть объяснено тем, что выражение pKey[0] & msb оптимизируется, когда BITS оценивается до значения больше 8.

Что касается вашего обновления, которое имеет целью показать, что аргумент функции фактически указывает на инициализированные данные, я склонен думать, что вы ищете не в том месте, или в другом месте, но не в том месте. код. То есть, вероятно, существует либо другой вызов checkMSB, который заставляет Valgrind жаловаться, либо тестируемый двоичный файл был собран из другой версии кода. Я не готов поверить, что все, что вы изложили в этом вопросе, является правдой или, по крайней мере, не соответствует тому, что вы, по-видимому, говорите.

...