Предупреждение может быть удалено на объекте C ++ с помощью setjmp

Правило состоит в том, что любая энергонезависимая нестатическая локальная переменная в фрейме стека, вызывающем setjmp , может быть сбита вызовом longjmp. Самый простой способ справиться с этим - убедиться, что фрейм, который вы вызываете setjmp, не содержит никаких таких переменных, которые вам нужны. Обычно это можно сделать, поместив setjmp в функцию отдельно и передав ссылки на вещи, которые были объявлены в другой функции, которая не вызывает setjmp:

#include <setjmp.h>
#include <vector>

int wrap_libcall(std::vector<int> &foo)
{
  jmp_buf env;
  // no other local vars
  if (setjmp(env)) return 1;
  // do stuff with your library that might call longjmp
  return 0;
}

int main(int argc, char**) { 
  std::vector<int> foo(argc);
  return wrap_libcall(foo);  
}

Также обратите внимание, что в этом контексте затирание на самом деле означает только сброс до значения, которое оно имело при вызове setjmp. Так что, если longjmp никогда не может быть вызван после модификации локального файла, вы тоже в порядке.

Изменить

Точная цитата из спецификации C99 на setjmp:

Все доступные объекты имеют значения, а все другие компоненты абстрактной машины имеют состояние на момент вызова функции longjmp, за исключением того, что значения объектов с автоматической продолжительностью хранения, которые являются локальными для функции, содержащей вызов соответствующего setjmp Макросы, которые не имеют изменчивого типа и были изменены между вызовом setjmp и вызовом longjmp, являются неопределенными.

Это не предупреждение, которое следует игнорировать, объекты longjmp () и C ++ не ладят друг с другом. Проблема в том, что компилятор автоматически вызывает деструктор для вашего объекта foo. Longjmp () может обойти вызов деструктора.

Исключения C ++ также разматывают кадры стека, но они гарантируют, что будут вызваны деструкторы локальных объектов. Нет такой гарантии от longjmp (). Чтобы узнать, будет ли longjmp () байтовым, вам необходимо тщательно проанализировать локальные переменные в каждой функции, которая может быть прервана раньше срока из-за longjmp (). Это непросто.

Как видно из строки 1035 в сообщении об ошибке, фрагмент кода значительно упростил фактический код проблемы. Вы зашли слишком далеко. Нет никакого представления о том, как вы используете слово «первый». Проблема в том, что компилятор не может понять этого даже в реальном коде. Он опасается, что значение first после ненулевого возврата от setjmp может оказаться не таким, как вы думаете. Это потому, что вы изменили его значение до и после первого вызова (нулевой возврат) на setjmp. Если переменная хранилась в регистре, значение, вероятно, будет другим, чем если бы оно хранилось в памяти. Итак, компилятор консервативен, давая вам предупреждение.

Чтобы сделать слепой шаг и ответить на вопрос, вы можете избавиться от предупреждающего сообщения, уточнив объявление «первый» с «изменчивым». Вы также можете попробовать сделать «первый» глобальным. Возможно, сбросив уровень оптимизации (флаг -O), вы можете заставить компилятор сохранять переменные в памяти. Это быстрые исправления, которые могут фактически скрыть ошибку.

Вам действительно стоит взглянуть на свой код и на то, как вы используете «first». Я сделаю еще одно безумное предположение и скажу, что вы можете исключить эту переменную. Может ли это имя, «первый», означать, что вы используете его для обозначения первого вызова (нулевого возврата) к «setjmp»? Если так, избавьтесь от этого - измените свою логику.

Если реальный код просто завершается ненулевым возвратом из 'setjmp' (как в фрагменте), тогда значение 'first' не имеет значения в этом логическом пути. Не используйте его по обе стороны от setjmp.

Быстрый ответ: сбросьте флаг -O1 или верните компилятор к более ранней версии. Любой из них заставил предупреждение исчезнуть в моей системе. Мне пришлось сначала собрать и использовать gcc4.4, чтобы получить предупреждение. (черт возьми, это огромная система)

Нет? Я думал, что нет.

Я действительно не понимаю всего, что C ++ делает со своими объектами, и как именно они освобождаются. Тем не менее, комментарий OP о том, что проблема не возникает, если вместо argc для размера вектора использовалось постоянное значение, дает мне возможность высунуть шею. Рискну предположить, что C ++ использует указатель __first при освобождении только тогда, когда начальное выделение не является константой. На более высоком уровне оптимизации компилятор больше использует регистры и возникает конфликт между выделениями до и после setjmp ... Не знаю, это не имеет смысла.

Общее значение этого предупреждения звучит так: «Вы уверены, что знаете, что делаете?» Компилятор не знает, знаете ли вы, каким будет значение '__first', когда вы выполните longjmp и получите ненулевой возврат от 'setjmp'. Вопрос в том, является ли его значение после (ненулевого) возврата значением, которое было помещено в буфер сохранения, или значением, которое вы создали после сохранения. В этом случае это сбивает с толку, потому что вы не знали, что используете '__first', и потому что в такой простой программе нет (явного) изменения на '__first'

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

Если вы упорствуете в выборе компилятора и оптимизации, есть исправление для программирования. Сохраните среду перед выделением вектора. Переместите setjmp в начало программы. В зависимости от использования вектора и логики ошибок в реальной программе могут потребоваться другие изменения.

изменить 21 января -------

мое обоснование (с использованием g ++ - mp-4.4 -Wextra -O1 main.cpp):

#include <setjmp.h>
#include <vector>
#include <iostream>

int main(int argc, char**) {
    jmp_buf env;
    int id = -1, idd = -2;

    if ((id=setjmp(env)))
        idd = 1;
    else 
        idd = 0;
    std::cout<<"Start with "<< id << " " << idd <<std::endl;
    std::vector<int> foo(argc );

    if(id != 4)
        longjmp(env, id+1);

    std::cout<<"End with "<< id << " " << idd <<std::endl;
}

Никаких предупреждений; а. произведено:

Начать с 0 0
Начать с 1 1
Начать с 2 1
Начать с 3 1
Начать с 4 1
Завершить с 4 1