Thread: Character pointer and integer pointer

You've run into a historical anomaly in the language.

Originally, in early versions of C, it was not possible to initialise any pointer using an array initialiser, with any type (a string literal can be used a special type of initialiser for arrays of chars). A number of vocal programmers then got tired of doing

Code:

    char s[] = "Hello";
    char *p = s;
       /*  use p */

and wanted to do this

Code:

    char *p = "Hello";

and lobbied to get that supported by some compilers. The vendors of the respective compilers then successfully lobbied to get it into the first C standard. And now we're stuck with it.

Some compilers do support such abominations (yes, that's what I think such constructs are) for other types.

Most modern compilers (whether they support such things for non-char types or not) will give warnings, if you turn up the warning levels. It is also considered good practice (at least, for C99 and later) for definition of CharP to have a const qualifier. Even then, it is an anomaly, even if a little less abominable.

There was some lobbying to get the anomaly supported by the standard for types other than char. I'm not sure if that got past the standards committee though, so don't know if that feature made it into C11. I hope it didn't.

My personal opinion is that both lines of your sample should be invalid (i.e. compilers should complain bitterly about both, and reject such code out of hand). The reason I say that is that programmers tend to misuse the "feature", and find themselves accidentally modifying string literals via a pointer (which is undefined behaviour) when they pass it to a function. I remember reading a report which claimed the number of errors in real-world code resulting from that construct is huge, but never confirmed veracity of that report. I have certainly seen programmers regularly make errors like that though.