For my guess at why -fmerge-constants may not be working for you: are you sure it's being properly passed as a linker setting in your build system? Post the command to link your program together.
But I agree with others that this is a bad idea. If you need an enum, use an enum. It's faster, safer, and clearer. Here's a few reasons why:
1)You shouldn't do at runtime what you can do at compile time. An enum is a compile time constant. A pointer is a runtime constant.
2)Char * may confuse your compiler because it could alias with anything. That means it can't reorder accesses to the char pointer with other operations involving pointers. Since reordering is crucial to optimisation, this can be a major blow in non obvious ways.
3)Is it "turquose" or "turquoise" or what? If you misspell a word, it's a different value, and there's nothing to catch your mistake. Likewise, is cyan a different color or not?
4)The use of standard patterns, like enums, makes your code easier to read by others and by you in the future. Being clever is a bad thing for this.
5)If the value is not a compile time literal, your method will check it against all constant pointers and always fail to match. That's an overhead for nothing. And there's no compile time check to guarantee the pointer passes is a literal. In contrast, an enum can match with a runtime integer, or optionally not try to match a runtime integer because it's a different type.
6)On a 64 bit system, pointers are 64 bits. But an enum can have a smaller memory and register footprint. This can also mean that more function parameters are passed by register.
7)You're relying on behaviour not guaranteed by the standard. That makes your code not portable and technically not C.
Edited by King Mir, 21 February 2014 - 09:48 AM.