This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

const *char returns versus *char returns

We have been moving our design from 8051 to ARM Cortex. I am seeing an error complaining that the return type does not match.

error: #120: return value type does not match the function type

static char *func(void);

In this function we may return a pointer to a const *char or *char. I can cast my way out of this but is this a good way of fixing the problem? We did not see this error with the Keil 8051 compiler only with the Keil ARM compiler. Not that it is a compiler problem. I don't want to run into a compilation problem with a version change.

Parents
  • It's not a compiler issue.

    It's part of the language to not like code that drops "const".

    If you sometimes have a const string to return, then the function should have a prototype with const to tell the user that the value must always be considered const.

    So the first time, it can be a big pain to make existing code const-correct. But in the long run, it's well worth it.

Reply
  • It's not a compiler issue.

    It's part of the language to not like code that drops "const".

    If you sometimes have a const string to return, then the function should have a prototype with const to tell the user that the value must always be considered const.

    So the first time, it can be a big pain to make existing code const-correct. But in the long run, it's well worth it.

Children
  • I fully expected a problem when I changed the function to static const char *func(void);
    Apparently you can return a non-const without an error?

    This only compiles I have not tried it.

  • Yes, a non-const variable can always be made stricter by making it const. What the compiler gets very upset about is the reverse - trying to strip the const protection.

    It's a bit similar to playing with char, short int, int, long int. You can assign a char to an int or a long int. But better compilers will warn if you do the reverse, since a char is too small to fit the full content of a long in a char. The compiler just doesn't like variables being "downgraded".

  • Since the GBA and the STR9 both use an ARM processor, would it be possible to natively run instructions from ROMs, with a wrapper that handles graphics, sound, and such? If so, would this have to be done without an OS, or can it done from within RTX?

    I am interested in leveraging the technology to provide my system with an advantage over our competitors by allowing it to do more than just what has been dictated by the specification.

  • How well abstracted are those functions? How familiar are you with the coding of those functions?