Передача указателя на локальную переменную: она безопасна?

Question

Например:

void func1(){ 
    int i = 123; 
    func2(&i); 
} 
void func2(int *a){ 
    *a = 456; 
} 

Когда func1 вызова func2, указатель на локальную переменную передается func2 - указатель указывает на стек. Это безопасно для правил C?

Спасибо.

Answer 1

Объем i составляет func1, и он переживает звонок до func2. Так что это совершенно безопасно.

Answer 2

Да, безопасно передавать указатель на локальную переменную, но вы не можете вернуть указатель на автоматическую локальную переменную из функции.

Answer 3

Да, ваш код в безопасности.

Пока срок жизни объекта не закончен, безопасно передавать локальные переменные, как вы.

Answer 4

Это безопасно для правил C?

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

Answer 5

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

Сейчас, как видим, i имеет всю жизнь до конца func1(). Как, func2() вызывается из func1(), а func1() еще не завершил выполнение, поэтому i по-прежнему действует.

Вот почему, как правило, передавая адрес локальной переменной в другой функции обычно допускается (время жизни переменной не закончена), но, return ИНГ адрес локальной переменной (сразу после return, локальные переменные функция прекратить существовать) не разрешено.

TL; DR: Вы можете смело использовать &i в качестве аргумента func2(), как показано здесь.

Answer 6

Как указано в большинстве ответов ранее, совершенно безопасно передавать указатель на func2() в вашем специальном случае.

В реальном мире часть программного обеспечения, однако, я считаю это вредным, поскольку у вас нет контроля над тем, что делает func2() с вашей переменной. func2() может создать псевдоним своего параметра, чтобы использовать его асинхронно в более поздний момент времени. И в это время локальная переменная int i может исчезнуть, когда этот псевдоним будет использоваться позже.

Так что с моей точки зрения передача указателя на локальную (автоматическую) переменную чрезвычайно опасна и ее следует избегать.

Вы можете сделать это, если вы объявляете переменную в func1(), как static int i;

В этом случае обеспечивается, что память i не будут переработаны и перезаписаны. Однако вам потребуется настроить блокировку Mutex для управления доступом к этой памяти в параллельной среде.

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

void func1() 
{ 
    // Data structure for NVMemory calls 
    valueObj_t NVMemObj; 

    // a data buffer for eeprom write 
    UINT8 DataBuff[25]; 
    // [..] 
    /* Assign the data pointer to NV Memory object */ 
    NVMemObj.record = &DataBuff[0]; 
    // [..] 
    // Write parameter to EEPROM. 
    (void)SetObject_ASync(para1, para2, para3, &NVMemObj); 
    return; 
} 

void SetObject_ASync(para1, para2, para3, valueObj_t *MemoryRef) 
{ 
    //[..] 
    ASyncQueue.CommandArray[ASyncQueue.NextFreeEntry].BufferPtr = MemoryRef->record; 
    //[..] 
    return; 
} 

В этом случае, данные в DataBuff давно нет, когда указатель в ASyncQueue.CommandArray[ASyncQueue.NextFreeEntry].BufferPtr используется для хранения данных в EEPROM.

Чтобы исправить этот код, по крайней мере необходимо объявить static UINT8 DataBuff[25]; Кроме того, считается, что также объявлено static valueObj_t NVMemObj, поскольку мы не знаем, что вызываемая функция выполняет с этим указателем.

Выражаясь кратко: TL; DR

Несмотря на то, что это законно в языке Си, я считаю это вредным передавать указатели на автоматические переменные в вызове функции. Вы никогда не знаете (и часто не хотите знать), что именно вызываемая функция выполняет с переданными значениями. Когда вызываемая функция устанавливает псевдоним, вы получаете большие неприятности.

Только мои 2 цента.