Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault?

Richard Damon <richard@damon-family.org> writes:

On 8/2/24 2:58 PM, James Kuyper wrote:
>

On 8/2/24 14:42, Richard Damon wrote:
>

On 8/2/24 2:24 PM, Keith Thompson wrote:
>

Richard Harnden <richard.nospam@gmail.invalid> writes:
[...]
>

Is there any reason not to always write ...
>
static const char *s = "hello, world";
>
... ?

>
...
>

There's no good reason not to use "const".  (If string literal objects
were const, you'd have to use "const" here.)

>
...
>

The one good reason to not make it const is that if you are passing it
to functions that take (non-const) char* parameters that don't
actually change that parameters contents.

>
Actually, that's not a good reason.  If you can't modify the function's
interface, you should use a (char*) cast, which will serve to remind
future programmers that this is a dangerous function call.  You shouldn't
make the pointer's own type "char *".

>
Depends on the library and how many times it is used.  It may be a
perfectly safe call, as the function is defined not to change its
parameter, but being external code the signature might not be fixable.

Right.  It isn't always feasible to assume source code can be
modified, especially without causing downstream problems.

Adding the cast at each call, may cause a "crying wolf" response that
trains people to just add the cast where it seems to be needed (even
if not warrented).

Exactly.  The last thing we want to do is have developers learn
habits that tend to push code in the direction of being less
safe.