C: warning assignment makes integer from pointer without a cast

[eatsleep]

C: "warning assignment makes integer from pointer without a cast"

1. I am trying to assign a color to the variable choice if it is equal to one of the 3 input numbers.

if(pred==1) {
		choice = "RED";
		}
	else if(pred==2) {
        	choice = "GREEN";
		}
	else if(pred==3) {
        	choice = "BLUE";
           	}

I have already initilized choice as a character variable and pred as an integer variable. I am not sure what I am missing but I keep getting the error "warning assignment makes integer from pointer without a cast".

 

[UltrafastPED]

"RED" is not a character variable - it is a string. The pointer conversion is from the string pointer.

 

[jedishrfu]

choice should be defined as:

char *choice;

if you used "char choice;" then C thinks of char as an 8-bit integer.

 

[D H]

choice should be defined as:

char *choice;

That should be const char* choice, not just char* choice.

Assigning to a pointer to a string such as "RED" is illegal (undefined behavior), so it's best to make the pointer a type that does not accept assignments.

 

[jedishrfu]

That should be const char* choice, not just char* choice.

Assigning to a pointer to a string such as "RED" is illegal (undefined behavior), so it's best to make the pointer a type that does not accept assignments.

Doesn't this depend on what he's trying to do?

Suppose this choice is in some sort of input loop where first its RED and then its BLUE ...

 

[nsaspook]

Doesn't this depend on what he's trying to do?

Suppose this choice is in some sort of input loop where first its RED and then its BLUE ...

The 'const char* choice' also tells the compiler that the 'data' at locations RED, BLUE, etc ... pointed to by 'choice' will not change so it can possibility optimize operations or memory storage using those locations.

EDIT: Looking at the C/C++ styles just to double check myself:
const char* == char const *

 

[D H]

Doesn't this depend on what he's trying to do?

Suppose this choice is in some sort of input loop where first its RED and then its BLUE ...

There's nothing wrong with that. const char * choice (or char const * choice, same thing) means that choice can be used on the left hand side of an assignment statement but that choice[1] cannot.

You are apparently thinking of char * const choice = "RED";, but that's a completely different data type. With this declaration, choice can only be assigned a value in the declaration statement. However, choice[1]='D'; is perfectly legal with this declaration. You can combine the two restrictions with the declaration const char * const choice = "RED";

 

[rcgldr]

Assigning to a pointer to a string such as "RED" is illegal (undefined behavior), so it's best to make the pointer a type that does not accept assignments.

It's my understanding that literal strings are like statics, and exist from start to termination of a program, so why should assigning a pointer to a literal string be undefined? Trying to change a value in the literal string via the pointer would be illegal / undefined behavior, but the pointer assignment shouldn't be an issue.

 

[jedishrfu]

There's nothing wrong with that. const char * choice (or char const * choice, same thing) means that choice can be used on the left hand side of an assignment statement but that choice[1] cannot.

You are apparently thinking of char * const choice = "RED";, but that's a completely different data type. With this declaration, choice can only be assigned a value in the declaration statement. However, choice[1]='D'; is perfectly legal with this declaration. You can combine the two restrictions with the declaration const char * const choice = "RED";

Thanks for the explanation, but I was referring to char * as the simplest solution to the OP question.

char *choice = "RED";

He can use choice for whatever he wants.

 

[nsaspook]

It's my understanding that literal strings are like statics, and exist from start to termination of a program, so why should assigning a pointer to a literal string be undefined? Trying to change a value in the literal string via the pointer would be illegal / undefined behavior, but the pointer assignment shouldn't be an issue.

It depends on the computer architecture and how strict the compiler is. With something like a uC with (modified) 'Harvard' architecture pointers to program literal strings that might be in ROM or flash and pointers to data in ram might require different memory access methods or pointer sizes, so a ram pointer assignment might be illegal or at least a warning.

 

[rcgldr]

It's my understanding that literal strings are like statics, and exist from start to termination of a program, so why should assigning a pointer to a literal string be undefined? Trying to change a value in the literal string via the pointer would be illegal / undefined behavior, but the pointer assignment shouldn't be an issue.

It depends on the computer architecture and how strict the compiler is.

The point I was making is how string literals are defined in the C89 and later standards. From the C89 standard, section 3.1.4:

A character string literal has static storage duration and type "array of char", and is initialized with the given characters. A wide string literal has static storage duration and type "array of wchar_t", and is initialized with the wide characters corresponding to the given multibyte characters. ...

Identical string literals of either form need not be distinct. If the program attempts to modify a string literal of either form, the behavior is undefined.

So it would seem that only an attempt to modify a string is undefined, not the usage of a pointer to access a literal string. The type "array of char" or "array of wchar_t" would be the same regardless of where the string literal was stored (ROM, RAM, code section of a program, ... ).

 

[nsaspook]

The point I was making is how string literals are defined in the C89 and later standards. From the C89 standard, section 3.1.4:
...
So it would seem that only an attempt to modify a string is undefined, not the usage of a pointer to access a literal string. The type "array of char" or "array of wchar_t" would be the same regardless of where the string literal was stored (ROM, RAM, code section of a program, ... ).

In general I agree on Von Neumann/Princeton architecture, C89 compliance pulls a little slight of hand here by hiding the details using "fat pointers" aka "generic pointers" on Harvard architecture but there are still many C compilers for embedded systems that are not strict C89 on this point (The Microchip C18 compiler is an example) for efficiency on small systems.
http://stackoverflow.com/questions/13484050/pointer-for-rom-variable-in-a-ram-variable

 

[D H]

It's my understanding that literal strings are like statics, and exist from start to termination of a program, so why should assigning a pointer to a literal string be undefined? Trying to change a value in the literal string via the pointer would be illegal / undefined behavior, but the pointer assignment shouldn't be an issue.

I wasn't clear with my previous post.

There's nothing wrong per se with char* ptr; ...; ptr="RED"; ...; ptr="BLUE"; What's wrong is assigning into that pointer: *ptr = 'A';. What's worse is that most compilers won't report this as an error. You don't find out until runtime.

Declaring the variable as a const char* pointer (or char const*, same thing) and assignments such as ptr="RED"; are still legal, but now *ptr = 'A'; becomes a compile-time error.

 

[jedishrfu]

I wasn't clear with my previous post.

There's nothing wrong per se with char* ptr; ...; ptr="RED"; ...; ptr="BLUE"; What's wrong is assigning into that pointer: *ptr = 'A';. What's worse is that most compilers won't report this as an error. You don't find out until runtime.

Declaring the variable as a const char* pointer (or char const*, same thing) and assignments such as ptr="RED"; are still legal, but now *ptr = 'A'; becomes a compile-time error.

I agree. I was assuming the OP had enough knowledge not to shoot himself in the foot with C. I used to teach C to others in my company as part of inhouse training and that assumption wasn't always true.