Hello all, I have a CUDA C piece of code in which I use the following function (prototype):
int getparlong (char *name, long *p);
and inside the code I call it as:
long nz;
getparlong(“nz”, &nz);
which works but gives the following warning during compilation:
warning: conversion from a string literal to “char *” is deprecated
I know that the best approach would be to correct the function call to “const char*” but I would prefer not to touch these modules. Is there a way to disable only this warning with nvcc? The -w flag works but suppresses all warnings, which is undesirable.
Personal opinion: There is never a good excuse for not cleaning up cruft. That stuff tends to accumulate. I have seen code with twenty years of accumulated cruft, and it is nearly impossible to maintain, at which point even experts do not want to touch it with a ten foot pole.
I have not tried this myself, but supposedly one can use this compilation flag to get the diagnostic ID for diagnostics emitted by the EDG-derived frontend:
-Xcudafe --display_error_number
Once one has a diagnostic’s ID, suppress it with:
-Xcudafe --diag_suppress=<diagnostic_id>
I am not entirely sure that the diagnostic you are seeing is emitted by FE, but it looks like the kind of diagnostics FE generates, so worth a try.
If this is instead a diagnostic emitted by the host compiler during compilation of host code, use the -Xcompiler flag of nvcc to pass a diagnostic disabling switch to the host compiler. For MSVC this would be /wd<diagnostic_id>. I do not recall whether gcc exposes diagnostic IDs or whether one has to first find the specific name of the diagnostic, and then use -Wno-<diagnostic_name>. I always use -Wall with gcc, so these details escape me.
[Later:]
The internet tells me the relevant gcc switch is -W{no-}write-strings.
suppresses the “string literal” warning and keeps all the other ones. Thanks!
The question is answered but the best solution (yet much more laborious) may be the one given in the personal opinion. In my case, it is an old package with many modules so it is not time feasible right now. Thanks again, cheers