Go Down

Topic: Compile error (Read 381 times) previous topic - next topic

Montmorency

That statement IS nonsense. There are several ways that you can do that. Casting the literal to a char * is one way, but that doesn't change the fact that what is passed is a pointer to a string literal.
Wow! You ripped my original statement out of context. A context that was explaining all that, including the possibility to cast to explicitly cast to `char *` (!)

And now you are stealing my statements from that context to pass as your own. O_o

A string literal is pointed to by a const char *. There is no getting around that fact.
Um... You are already contradicting yourself. Just a second ago you clearly (and correctly) stated that there is a way to get around that fact: casting it to `char *`. What gives?

The function that you are passing the pointer to expects that, or it doesn't. There is no getting around that fact, either.
Um... Welcome to the real world. I'm a huge fan of const correctness, but unfortunately there are copious amounts of functions out there that receive their input as pointers (or references) to modifiable data, even though they don't intend to modify it. C code suffers from this issue more often than C++ code, but both are guilty.

In this case the fact is we are doing with third-party code from a repository (read: a code that we should not really modify) that suffers from this unfortunate problem.

The language is not. Your interpretation of some code, and resulting behavior, is.
I've been using C++ for more than 20 years.
Great. But alas I've seen people who "used" the language for even longer periods of time, but... you know... never really cared to learn it properly.

PaulS

Quote
Um... You are already contradicting yourself. Just a second ago you clearly (and correctly) stated that there is a way to get around that fact: casting it to `char *`. What gives?
You can't get around the fact that a string literal is pointed to by a const char *. You can pretend that a const char * is a char *, when passing the pointer to a function that expects a pointer to char BUT that doesn't actually intend to modify the char array pointed to.

Trying to pretend that a const char * is a char *, when the function DOES actually modify the pointed to array is a recipe for disaster.

Quote
In this case the fact is we are doing with third-party code from a repository (read: a code that we should not really modify) that suffers from this unfortunate problem.
The fact is that OP does not NEED to use this function. OP might want to, because it is easy. But, then OP needs to be prepared to deal with the fact that the function is poorly declared.

Quote
But alas I've seen people who "used" the language for even longer periods of time, but... you know... never really cared to learn it properly.
That wouldn't be me. I don't keep the references handy, so I occasionally get a fact (or two) wrong. But I do understand pointers and arrays and casting, and what casts are valid and what casts are not. I can recognize a poorly written/not well tested function when I see it.
The art of getting good answers lies in asking good questions.

Montmorency

You can't get around the fact that a string literal is pointed to by a const char *. You can pretend that a const char * is a char *, when passing the pointer to a function that expects a pointer to char BUT that doesn't actually intend to modify the char array pointed to.

Trying to pretend that a const char * is a char *, when the function DOES actually modify the pointed to array is a recipe for disaster.
Trying to modify a `const` object through a non-const access path is a disaster. It leads to undefined behavior. Nobody here is arguing with that. But however true that is, this is not germane to the situation at hand. Nobody is trying to modify string literals here. I don't know why you keep bringing this up.

And yes, you can "pretend" that a string literal is a `char *`. C++ language (as well as C) provides a very clear separation between:

1. The act of generating a non-constant access path (a pointer or a reference) to a constant object.
2. The act of actually trying to modify a constant object through that non-constant access path.

In C and C++ you are allowed to forcefully cast away constness from constant objects (step 1) as much as you want. The behavior is well-defined by the language. You are allowed to do it, as long as you don't make any modification attempts (step 2).

PaulS

Quote
Nobody is trying to modify string literals here. I don't know why you keep bringing this up.
Since the function is trying to modify the value pointed to, the function should promise not to do that. THAT is what the discussion is about. Since it did not, then the discussion began to focus on how to get around that.

The art of getting good answers lies in asking good questions.

Montmorency

#19
Apr 18, 2019, 04:41 pm Last Edit: Apr 18, 2019, 04:43 pm by Montmorency
Since the function is trying to modify the value pointed to, the function should promise not to do that. THAT is what the discussion is about. Since it did not, then the discussion began to focus on how to get around that.
It definitely should! Nobody's arguing with that either. But let me repeat what I already said above

"I'm a huge fan of const correctness, but unfortunately there are copious amounts of functions out there that receive their input as pointers (or references) to modifiable data, even though they don't intend to modify it. C code suffers from this issue more often than C++ code, but both are guilty."

Authors of that third-party library should definitely update their code. But I don't think that telling the OP what authors of that third-party library "should" do can help the OP much.

Go Up