Это нарушает семантику `restrict`? - PullRequest
Новая
       18

Это нарушает семантику `restrict`?

0 голосов
/ 15 декабря 2018

ПРИМЕЧАНИЕ - Это очень похоже на ограничение ограничения и арифметику указателей , но не является дубликатом.Автор этого поста присваивал результат операций с указателем restrict этому же указателю, а я присваивал результат операций с указателем restrict в качестве аргумента параметра функции restrict.

Я понимаю значение restrict по большей части, и я начинаю привыкать объявлять параметры функции restrict всякий раз, когда это применимо.Но я не уверен, злоупотребляю ли я этим здесь или нет. 

struct DynArray
{
    void* data;
    size_t elemCount;
    size_t len;
};

void dyn_append(DynArray* restrict dst, const void* restrict src, size_t srcLen, size_t elemSize)
{
    size_t oldElemCount = dst->elemCount;
    dyn_setElemCount(dst, dst->elemCount + srcLen, elemSize);    // might write to `*dst`
    if (dst->data)    // `dst->data` is set to `NULL` if reallocation fails.
        // The next line might violate "restrict-ness" of `dst`.
        memcpy((char*)dst->data + elemSize*oldElemCount, src, elemSize * srcLen);
}

В частности, я имею в виду (char*)dst->data + elemSize*oldElemCount в вызове memcpy.Если бы я передал dst сам, а не приведенный выше аргумент, я знаю, что он будет действительным, так как я бы назначил его параметру функции, которая сама по себе restrict.Меняет ли в этом случае тот факт, что аргумент является результатом операций над dst, а не dst, сам по себе что-то меняет?Я считаю, что гарантия того, что аргумент не будет псевдонимом, содержится в гарантии того, что dst не будет псевдонимом.

1 Ответ

0 голосов
/ 15 декабря 2018

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

...