Как избавиться от предупреждений "устаревшее преобразование строковой константы в" char * "в GCC?
Итак, я работаю над чрезвычайно большой базой кода и недавно обновился до gcc 4.3, который теперь вызывает это предупреждение:
warning: deprecated conversion from string constant to ‘char*’
Очевидно, что правильный способ исправить это - найти каждое объявление вроде
char *s = "constant string";
или вызов функции, например:
void foo(char *s);
foo("constant string");
и сделайте из них указатели const char. Однако это означало бы прикоснуться как минимум к 564 файлам, что не является задачей, которую я хочу выполнять в данный момент. Сейчас проблема в том, что я работаю с -werror, поэтому мне нужен способ подавить эти предупреждения. Как я могу это сделать?
Я просмотрел дискуссии о том, как подавлять сообщения об ошибках и какие должны быть правильные замены. У меня нет никаких мнений по этому поводу. Однако я думаю, что Мэтт на правильном пути. Определите, что вы хотите заменить чем. Вам просто нужно правильное регулярное выражение (я). Внесите изменения в копию. Используйте "diff", чтобы сравнить их с оригиналом. Внесение изменений с помощью sed выполняется быстро, легко и бесплатно, а diff также выполняется быстро, легко и бесплатно. Попробуйте и посмотрите, сколько изменений вам нужно просмотреть. Опубликуйте то, что вы хотите заменить, и позвольте пользователям предлагать замены регулярным выражениям.
Во всем обсуждении отсутствует точка Почему, это проблема, которая вообще требует исправления в соответствии с предупреждением gcc. Причина в ответе Дэвида Шварца stackoverflow.com/questions/56522654/….
Ответы 23
Я считаю, что передача -Wno-write-strings в gcc подавит это предупреждение.
Можно ли отключить его для каждого файла с помощью прагм.
@PriyankBolia bdonlan прокомментировал ответ Роба Уокера, что он может использовать #pragma GCC diagnostic ignored "-Wwrite-strings".
За исключением случаев, когда вы управляете API, и в этом случае ответ @ John ниже об изменении подписи для принятия const char * является более правильным.
ЭТО УЖАСНО ПЛОХАЯ ПРАКТИКА, и мне жаль, что она получила все эти голоса. Предупреждений нет, поэтому вы их игнорируете. Предупреждения говорят вам: «чувак, ты делаешь что-то, что может быть неправильно, будь осторожен», и тебе следует подавлять их только тогда, когда ты хочешь ответить типа «заткнись, я знаю, что делаю», что, скорее всего, не в случае с младенческими программистами.
Я согласен, вам не следует избавляться от предупреждения и вместо этого использовать решение, предоставленное Джоном. Жаль, что это принятый ответ!
это, очевидно, нужно делать на этапе компиляции, а не на заключительном этапе связывания.
Если вы хотите сохранить предупреждения, но не рассматривать их как ошибки, вы можете сделать "-Wno-error = write-strings".
Почему не лучший ответ "Don't pass -werror"? Это решает не только эту проблему, но и следующую.
Проблема с предупреждениями заключается в том, что действительно важные предупреждения слишком легко потеряться в море мелких предупреждений, отчетов о ходе создания и т. д. В то время как ошибки привлекают немедленное внимание, потому что они вызывают сбой сборки. IMO во время разработки лучше сделать отдельные предупреждения нефатальными с помощью "-Wno-error =", чем полностью избавиться от Werror.
Отключение важных предупреждений - это действительно плохо. Согласовано. Тем не менее, чем это предупреждение вообще полезно? Я не могу понять, как «исправление» этого предупреждения улучшит код и никоим образом не уменьшит ошибочное поведение. Я здесь не прав?
@FrederickOllinger, вы наверняка получили это с тех пор, но просто чтобы ответить на комментарий, он делает код более безопасным и правильным, потому что, когда функция принимает char* и пытается его изменить, если вы вызываете функцию со строковым литералом - который не доступен для записи - вы получите ошибку сегментации.
Ознакомьтесь с поддержкой gcc Диагностическая прагма и списком -W параметры предупреждений (изменено: новая ссылка на параметры предупреждений).
Для gcc вы можете использовать директивы #pragma warning, как описано в здесь.
Это действительно так: #pragma GCC диагностика игнорирует "-Wwrite-strings"
Этот ответ на самом деле не содержит ответа.
Если это активная база кода, вы все равно можете обновить ее. Конечно, внести изменения вручную невозможно, но я считаю, что эту проблему можно решить раз и навсегда с помощью одной-единственной команды sed. Однако я не пробовал, так что отнеситесь к следующему с недоверием.
find . -exec sed -E -i .backup -n \
-e 's/char\s*\*\s*(\w+)\s*= "/char const* = "/g' {} \;
Это может не найти всех мест (даже без учета вызовов функций), но это уменьшит проблему и позволит выполнить несколько оставшихся изменений вручную.
который в любом случае решает только предупреждения объявлений, а не вызовы функций +1 для sed fu: p
The problem right now is that I'm running with -Werror
Это твоя настоящая проблема, ИМО. Вы можете попробовать несколько автоматизированных способов перехода от (char *) к (const char *), но я бы положил деньги на то, чтобы они не просто работали. По крайней мере, для некоторых работ вам нужно будет привлечь человека. На короткое время просто игнорируйте предупреждение (но IMO оставьте его включенным, иначе оно никогда не будет исправлено) и просто удалите -Werror.
Причина, по которой люди используют -Werror, заключается в том, что предупреждения делать исправляются. В противном случае они никогда не исправятся.
Люди используют -Werror потому, что они работали только над игрушечными проектами, или они мазохисты. Если ваш код не может быть собран из-за обновления GCC, это настоящая проблема, когда у вас 100k + LOC. Дито. кто-то добавляет в сборку мусор, например "-Wno-write-strings", чтобы избавиться от надоедливых предупреждений (как предполагает самый высокий рейтинг в этом сообщении).
в этой теме есть явные разногласия, например программист.97things.oreilly.com/wiki/index.php/…
@ Джеймс: Вы подметили интересный момент, но должен быть способ получше. Кажется бессмысленным не устранять предупреждения немедленно - как узнать, когда новый код вызвал новое предупреждение, если вы не удалили все старые предупреждения? По моему опыту, это просто приводит к тому, что люди игнорируют предупреждения, которые им не следует игнорировать.
@James: наш игрушечный проект - 1,5+ M LOC (многоязычный). Как сказал nobar, -Werror позволяет избежать игнорирования предупреждений, которых не должно быть, и да, каждый раз, когда возникает новая версия компилятора, мы должны перепроверять все. -Wno-write-strings просто используется при использовании Boost для оболочек Python в файловом режиме, потому что мы не собираемся переписывать Boost (и сейчас, 2017, мы предпочитаем не использовать Boost, а C++ 11 / cython). Каждое проигнорированное предупреждение должно затем периодически проверяться проверкой качества, чтобы увидеть, можно ли теперь избежать с помощью кода или пока это невозможно.
-Werror был разницей между угрозой отказа одного из наших клиентов отменить крупный контракт и временем безотказной работы пять девяток. Некоторые сообщения были бессмысленными стилистическими проблемами; многие ожидали ошибки.
Почему вы не используете опцию -Wno-deprecated, чтобы игнорировать устаревшие предупреждающие сообщения?
У меня была аналогичная проблема, решил я вот так:
#include <string.h>
extern void foo(char* m);
int main() {
// warning: deprecated conversion from string constant to ‘char*’
//foo("Hello");
// no more warning
char msg[] = "Hello";
foo(msg);
}
Это подходящий способ решить эту проблему? У меня нет доступа к foo, чтобы адаптировать его к const char*, хотя это было бы лучшим решением (потому что foo не меняет m).
@elcuco, что бы вы предложили? Я не мог редактировать foo и пытался найти решение, которое не требовало подавления предупреждения. В моем случае последнее было скорее упражнением, но для оригинального плаката это казалось важным. Насколько я могу судить, мой ответ - единственный, который решал бы как мои условия, так и условия OP одновременно, так что это мог бы быть ценный ответ для кого-то. Если вы считаете, что мое решение недостаточно хорошее, не могли бы вы предоставить альтернативу? (Это не включает редактирование foo или игнорирование предупреждения.)
если мы предположим, что foo правильно закодирован (что, к сожалению, не похоже на код, о котором говорит Джош Мэтьюз), это лучшее решение. это потому, что если функции действительно нужно изменить строку 'msg', передавая ей постоянную строку, код нарушится, верно? но в любом случае это, похоже, не отвечает на вопрос, потому что ошибки уже есть в старом коде, а не в новом, поэтому ему все равно придется изменить старый код.
Я тоже придерживался этого подхода. И если кто-то ищет здесь случаи char ** в PyArg_ParseTupleAndKeywords, я делаю что-то вроде этого: static char kw[][16] = {"mode", "name", "ip", "port"}; static char * kwlist[] = {kw[0], kw[1], kw[2], kw[3], NULL};
@elcuco: я не уверен, как работают статические массивы C++. Будет ли это копировать действительно какие-то данные, а не только указатель?
Хотя этот подход может иметь свои достоинства, в некоторых случаях применение его вслепую, ИМО, скорее всего, принесет больше вреда, чем пользы. Применение этого вслепую может легко привести к зависанию указателей. Это также приведет к раздуванию кода бессмысленными копиями строк.
Вы также можете создать доступную для записи строку из строковой константы, вызвав strdup().
Например, этот код генерирует предупреждение:
putenv("DEBUG=1");
Однако следующий код этого не делает (он делает копию строки в куче перед передачей ее putenv):
putenv(strdup("DEBUG=1"));
В этом случае (и, возможно, в большинстве других) отключение предупреждения - плохая идея - оно есть не просто так. Другой вариант (сделать все строки доступными для записи по умолчанию) потенциально неэффективен.
Послушайте, что вам говорит компилятор!
И это также приводит к утечке памяти, выделенной для этой записываемой строки.
Да, это так - это специально. Не проблема с одноразовым (например, инициализационным) кодом, как указано выше. Или вы можете управлять памятью самостоятельно и высвободить ее, когда закончите с ней.
Частный случай putenv() чреват - это не лучший выбор (по крайней мере, не без гораздо большего обсуждения того, что делает putenv(), чем в этом ответе). Это отдельное обсуждение. (Обратите внимание, что спецификация POSIX для поведения putenv() проблематична из-за устаревших реализаций до того, как был определен POSIX.) IIRC, в недавнем (в этом тысячелетии) выпуске библиотеки GNU C была ошибка, связанная с поведением putenv(). меняется и возвращается обратно.)
Я не могу использовать переключатель компилятора. Итак, я повернул это:
char *setf = tigetstr("setf");
к этому:
char *setf = tigetstr((char *)"setf");
+1 - вы не можете изменить lvalue приложений, только rvalue. это помогло решить настоящую проблему. другие просто помогают обойти некоторые проблемы с компилятором.
Что действительно раздражает, так это то, что tigetstr () должен быть прототипирован с помощью (const char *), а не (char *)
Когда я делаю это, я получаю «предупреждение: приведение типа« const char * »к типу« char * »вместо этого отбрасывает константу». Мне пришлось использовать const_cast, чтобы избавиться от всех предупреждений: const_cast <char *> ("setf")
Я думаю, что константное приведение - первое приемлемое решение на этой странице (за исключением изменения API).
Test string - это константная строка. Итак, вы можете решить так:
char str[] = "Test string";
или же:
const char* str = "Test string";
printf(str);
см. эту ситуацию:
typedef struct tagPyTypeObject
{
PyObject_HEAD;
char *name;
PrintFun print;
AddFun add;
HashFun hash;
} PyTypeObject;
PyTypeObject PyDict_Type=
{
PyObject_HEAD_INIT(&PyType_Type),
"dict",
dict_print,
0,
0
};
следите за полем имени, в gcc он компилируется без предупреждения, но в g ++ это будет, я не знаю почему.
gcc подразумевает обработку файла как исходный файл C, g ++ рассматривает его как исходный файл C++, если не переопределить с помощью -x ?? вариант. Итак, разные языки, c и C++, имеют тонкие различия в том, о чем следует предупреждать.
Почему бы просто не использовать приведение типов?
(char*) "test"
Вот как это сделать в файле, так что вам не нужно изменять свой Makefile.
// gets rid of annoying "deprecated conversion from string constant blah blah" warning
#pragma GCC diagnostic ignored "-Wwrite-strings"
Вы можете позже ...
#pragma GCC diagnostic pop
PyTypeObject PyDict_Type=
{ ...
PyTypeObject PyDict_Type=
{
PyObject_HEAD_INIT(&PyType_Type),
"dict",
dict_print,
0,
0
};
следите за полем имени, в gcc он компилируется без предупреждения, но в g ++ это будет, я не знаю почему.
в gcc (Compiling C) по умолчанию активна -Wno-write-strings.
в g++ (Compiling C++) -Wwrite-strings активна по умолчанию
Вот почему есть другое поведение.
У нас использование макросов Boost_python генерирует такие предупреждения.
Итак, мы используем -Wno-write-strings при компиляции C++, так как мы всегда используем -Werror.
просто используйте параметр -w для g ++
пример:
g ++ -w -o simple.o simple.cpp -lpthread
Помните, что это не предотвращает устаревание, а предотвращает отображение предупреждающего сообщения на терминале.
Теперь, если вы действительно хотите избежать устаревания, используйте ключевое слово const, например:
const char* s = "constant string";
Любые функции, в которые вы передаете строковые литералы "I am a string literal", должны использовать char const * в качестве типа вместо char*.
Если собираетесь что-то исправить, исправляйте правильно.
Объяснение:
Вы не можете использовать строковые литералы для инициализации строк, которые будут изменены, потому что они имеют тип const char*. Отказ от констант для их последующего изменения - это неопределенное поведение, поэтому вам нужно скопировать строки const char*, char по char, в динамически выделяемые строки char*, чтобы изменить их.
Пример:
#include <iostream>
void print(char* ch);
void print(const char* ch) {
std::cout<<ch;
}
int main() {
print("Hello");
return 0;
}
Хотя это правда, у вас не всегда есть контроль над сторонними API, которые могут неправильно использовать char * / const char *, поэтому в этом случае я обычно использую.
@ppumkin К сожалению, многие строковые функции стандартной библиотеки C принимают аргументы как char* даже для строк, которые не будут изменены. Если вы возьмете параметр как char const* и передадите его стандартной функции, принимающей char*, вы попадете в это. Если библиотечная функция не будет управлять строкой, вы можете отказаться от const.
Просто потому, что это не всегда возможно, не означает, что это не предпочтительный вариант во многих случаях, когда это предупреждение появляется в обычном производственном коде.
Даже если я чувствую, что это правильный ответ, я считаю, что ему не хватает надлежащего объяснения. Не могли бы вы отредактировать и добавить объяснение? Это не требует подробностей. Может, пару слов и ссылку?
Теперь я полностью понимаю решение и функциональность строковых литералов. Но, возможно, другие этого не делают, поэтому я "придерживаюсь" необходимости объяснения.
Я не понимаю, как применить ваше решение :(
это должен быть принятый ответ, поскольку в нем говорится об использовании const char * вместо char * для постоянных строк.
Выполните приведение типов из постоянной строки в указатель char, т.е.
char *s = (char *) "constant string";
Вместо:
void foo(char *s);
foo("constant string");
Это работает:
void foo(const char s[]);
foo("constant string");
Это правильный способ сделать это, поскольку вы не должны передавать (константную) строку функции, которая в любом случае ожидает непостоянную строку!
В C++ используйте const_cast, как показано ниже.
char* str = const_cast<char*>("Test string");
Заменять
char *str = "hello";
с
char *str = (char*)"hello";
или если вы вызываете функцию:
foo("hello");
замените это на
foo((char*) "hello");
Спасибо всем за помощь. Выбор здесь и там приходит это решение. Это компилируется чисто. Код еще не тестировал. Может быть, завтра...
const char * timeServer[] = { "pool.ntp.org" }; // 0 - Worldwide
#define WHICH_NTP 0 // Which NTP server name to use.
...
sendNTPpacket(const_cast<char*>(timeServer[WHICH_NTP])); // send an NTP packet to a server
...
void sendNTPpacket(char* address) { code }
Я знаю, что в массиве timeServer всего 1 элемент. Но могло быть и больше. Остальные пока закомментированы для экономии памяти.
В C++ замените:
char *str = "hello";
с:
std::string str ("hello");
И если хотите сравнить:
str.compare("HALLO");
I don't understand how to apply your solution :( – kalmanIsAGameChanger
Работая с Arduino Sketch, у меня была функция, вызывающая мои предупреждения.
Original function: char StrContains(char *str, char *sfind)
Чтобы отключить предупреждения, я добавил const перед char * str и char * sfind.
Modified: char StrContains(const char *str, const char *sfind).
Все предупреждения исчезли.
Это правильный ответ, согласно предупреждению: «предупреждение: устаревшее преобразование строковой константы в« char * »».
Передавая string constants функциям, напишите его как:
void setpart(const char name[]);
setpart("Hello");
вместо const char name[] можно также написать const char \*name
Мне удалось удалить эту ошибку:
[Warning] deprecated conversion from string constant to 'char*' [-Wwrite-strings]
Когда вы решите заменить 554 строки, sed - ваш хороший друг. Однако сначала убедитесь, что вы сделали резервную копию.