Pointer dangling or not

This is an excerpt from an e-book

Code:

---

char *someFun()
                {
                char *temp = “string constant";
                return temp;
                }
                int main()
                {
                puts(someFun());
                }

---

Code:

---

Answer:
                string constant
Explanation:
                The program suffers no problem and gives the output
correctly because the character constants are stored in code/data area and not
allocated in stack, so this doesn’t lead to dangling pointers.

---

Is it correct?? Are other pointers also stored in data area.

Seems good to me.

Your explanation is the details that apply with some implementations. The more correct justification is in the C++ standard, section 2.13.4, paragraph 1, which starts with;

"A string literal is a sequence of characters (as defined in 2.13.2) surrounded by double quotes, optionally beginning with the letter L, as in "..." or L"...". A string literal that does not begin with L is an ordinary string literal, also referred to as a narrow string literal. An ordinary string literal has type “array of n const char” and static storage duration (3.7), where n is the size of the string as defined below, and is initialized with the given characters. ...."

In the above I've highlight the relevant bits: string literals are stored statically.

Quote:

---

Originally Posted by grumpy

"A string literal is a sequence of characters (as defined in 2.13.2) surrounded by double quotes, optionally beginning with the letter L, as in "..." or L"...". A string literal that does not begin with L is an ordinary string literal, also referred to as a narrow string literal. An ordinary string literal has type “array of n const char” and static storage duration (3.7), where n is the size of the string as defined below, and is initialized with the given characters. ...."

---

I took the liberty of highlighting something different. You should never assign a string literal to a non-const pointer, even though most compilers (and perhaps even the standard, can't remember) allow it for C compatibility.

Thus it should be:

Code:

---

const char *someFun()
{
        const char *temp = "string constant";
        return temp;
}
int main()
{
        std::cout << someFun() << "\n";
}

---

Quote:

---

Originally Posted by CornedBee

I took the liberty of highlighting something different. You should never assign a string literal to a non-const pointer, even though most compilers (and perhaps even the standard, can't remember) allow it for C compatibility.

Thus it should be:

Code:

---

const char *someFun()
{
    const char *temp = "string constant";
    return temp;
}
int main()
{
    std::cout << someFun() << "\n";
}

---

---

Hmm... Not sure if I'm following you here, CornedBee.

You may not want temp to be a const expression. You certainly may want to have a string initialized from a string literal.

It's a const char *, so it merely points to the constant string literal in memory. You'd want it to be const, because as mentioned, string literals are constant. You can't modify them.

Yes... I understand const T*.

However, that is a far shot from saying "You should never assign a string literal to a non-const pointer, even though most compilers (and perhaps even the standard, can't remember) allow it for C compatibility.". That's what is confusing me.

There's an implicit cast there, I agree. The constness of the string literal gets droped. But how else do you expect to initialize non const c-style strings?

You shouldn't be able to.

I'm sorry... but I must insist because either i'm being thick here or you are not putting much effort into your reply.

"You shouldn't be able to" ?

The standard also designates the term literal as const.

Quote:

---

Originally Posted by page15 footnote

The term “literal” generally designates, in this International Standard, those tokens that are called “constants” in ISO C.

---

So what to say of int value = 15; ?

> int value = 15;
You've requested this memory for your use. String literals are not meant to be changed ever because they are stored in memory that is not meant to be overwritten, merely accessed. This is to protect you from wantonly changing the return values of some functions.

This chrashes as it should.

Code:

---

#include <iostream>
using namespace std;

char *f()
{
  return "hello";
}

int main()
{
  char *ptr = f();
  *ptr = 'j';
  cout << ptr << "\n";
  return 0;
}

---

The sane way is to allocate memory for your string literal so that you can change it.

Code:

---

#include <iostream>
#include <cstring>

using namespace std;

const char *f()
{
  return "hello";
}

int main()
{
  char arr[6];
  strcpy(arr, f());
  *arr = 'j';
  cout << arr << "\n";
  return 0;
}

---

Quote:

---

Originally Posted by Mario F.

So what to say of int value = 15; ?

---

Apple; orange. The 15 is the item of interest in the comparison.

[edit]I think I'm beginning to get where you are going, but could you please post an example of the string variety since it is highly germane to the discussion.

The value 15 itself is constant. This doesn't work:

Code:

---

15 = 7;

---

Likewise, strings are constant. This shouldn't work:

Code:

---

strcpy("hippo", "potamus");

---

But, as mentioned, some C compilers allowed it.

You can change the value of a variable that has been assigned the value of an integral literal. You can't change the contents of a literal string. Changing the contents of a string is like doing this:

Code:

---

int *p = &7;
*p = 5;

---

You'd change the very meaning of 7 itself within your program!

[edit] That post took a while for me to compile. Two people beat me to it. :) [/edit]

I'm not discussing string literals per-se. A string literal has the form const char*. That was established here, is established in the standards, and I know it. But that is not my point.

My point is stating that you should not assign a string literal to anything other than a const char*.

I don't think this is a correct statement. Or maybe a better way to put it, is incomplete.

What I believe should have been said was something along the lines of "you can assign a string literal to a char* as a shorthand to having to do something like:
char* temp = {'H','e','l','l','o',' ','W','o','r','l','d'}"

Because the standard allows char* identifier = string_literal

Quote:

---

Originally Posted by Mario F.

What I believe should have been said was something along the lines of "you can assign a string literal to a char* as a shorthand to having to do something like:
char* temp = {'H','e','l','l','o',' ','W','o','r','l','d'}"

Because the standard allows char* identifier = string_literal

---

Hm. First, that's not quite a C-string. If it was, this is exactly the case for const -- you cannot modify what it's pointing to, so the pointer should reflect this. (I thought you may be going in the direction of arrays for a moment.) [edit]Or maybe you still are?

Well, but those situations are no different than those created by a int* or, actually T*

Maybe you guys are right. Maybe i'm totally missing the point. I credit you guys much more knowledgeable than me in C++, for I to be able to keep up with this argument for much longer in a clear conscience :)

Quote:

---

Originally Posted by ISO-IEC 14882-2003 (4.2) discussing Standard (implicit) conversions

A string literal (2.13.4) that is not a wide string literal can be converted to an rvalue of type “pointer to
char”; a wide string literal can be converted to an rvalue of type “pointer to wchar_t”. In either case,
the result is a pointer to the first element of the array. This conversion is considered only when there is an
explicit appropriate pointer target type, and not when there is a general need to convert from an lvalue to an
rvalue. [Note: this conversion is deprecated. See Annex D. ] For the purpose of ranking in overload resolution
(13.3.3.1.1), this conversion is considered an array-to-pointer conversion followed by a qualification
conversion (4.4). [Example: "abc" is converted to “pointer to const char” as an array-to-pointer conversion,
and then to “pointer to char” as a qualification conversion. ]

---

I'm sure you guys know this. And as such a string literal can be assigned to a char*. But maybe i'm missing the point as to what the original CornedBee intention was.

Well... no one is certainly forcing you to use const correctness. The thing is, even reasonably intelligent people will screw up: while you can make a char pointer reference a string literal it is not a wise idea in practice, since there are many ways to make the pointer invalid. While the code in my earlier post does not reflect this part of life (as I did it purposefully), it can happen.

I believe this was Corned Bee's intent. In fact, it's probably an argument for using const pointers to const char, but that's an assumption.

CornedBee's intention was, I presume, to say that a non-const pointer should never be initialised so it points at a string literal (which is of type n const char *).

He's right in one way, and wrong in another.

The relationship between string literals and pointers to char has been an anomaly in the language, almost since Adam was a boy. Initialising a pointer to char with a string literal is the only means supported by C or C++ by which a pointer can be initialised (effectively) with an array of elements. The reason it was introduced into C in (during the 1970s IIRC: definitely well before the standards were written) was as a convenience for lazy programmers who did not want to create a pointer, create a string literal, and then assign the pointer to point at the string literal. It was a fairly common use case, and programmers whined about having to use two lines of code;

Code:

---

    char x[] = "Hello";  /*  string literal to support a char array */
    char *px = x;

---

when they were thinking it could be done in one, i.e.

Code:

---

    char *px = "Hello";

---

Hence the initialisation of a char pointer with a string literal was born. In those days, the const keyword was not part of the language, so there was no const attribute. However, in practice, compilers placed string literals into some form of read-only memory, so modifying a string literal tended to result in a program crash.

During the development of the C standard (which was ratified in 1989 by ANSI, and then adoped in 1990 by ISO) the const keyword was born. String literals, however, did not wind up with a const attribute, and initialisation of pointers using a string literal was still allowed in the interests of backward compatibility. This was because of the large amount of legacy code initialising non-const char pointers with string literals (obviously lazy programmers who whine are widespread). In both C standards, a string literal is an array of char.

Along came the C++ standardisation process, which made a string literal into an array of const char and flagged initialisation of a non-const pointer with a const string literal as a "bad thing". They marked it as a deprecated feature (deprecating is a means by which a standards committee can state that use of a feature is considered bad practice, and that it will be removed from some future version of the standard). The reason they did this is that they were required to support backward compatibility to C (the 1989 standard). The end result of that is that C++ compilers are required to allow use of a string literal to initialise a non-const pointer. Deprecating means it is recognised as bad practice and (in fact) a fair few C++ compilers give non-fatal warnings (i.e. they complain about it, but let it compile anyway) when code uses this feature. While compiler vendors are free to choose not to support deprecated features, they often do because they must deal with programmers whining when they get fatal errors when compiling legacy code - the path of least resistance for compiler vendors is often to support deprecated features.

The end result of that is, literally, that CornedBee is both right and wrong. He is right in the sense that initialising a non-const pointer with a string literal is bad practice, and that it may be removed from a future version of the C++ standard. He is wrong in the sense that it is a feature which is used very commonly in legacy C and C++ code, so the majority of compilers support it.