What are the different invalid characters that I am not allowed use in a macro ?
It seems that #define TE$T 8
is working, so $
is valid.
Does somebody have a list of the invalid characters ? (or on the contrary the list of the valid ones).

- 2,807
- 2
- 32
- 57

- 13
- 1
- 5
-
A macro identifier may not start with a number. – alk Jun 01 '16 at 12:19
4 Answers
It's your compiler that allows usage of $
as an identifier. It's not standard and you shouldn't expect other compilers to provide it or your compiler to allow it, if you compile with -pedantic
or similar.
In the C11 draft's common extension appendix:
J.5.2 Specialized identifiers
1 Characters other than the underscore _, letters, and digits, that are not part of the basic source character set (such as the dollar sign $, or characters in national character sets) may appear in an identifier (6.4.2).
Section 6.4.2 shows what characters every conforming compiler has to support:
6.4.2 Identifiers
6.4.2.1 General
Syntax 1 identifier:
identifier-nondigit
identifier identifier-nondigit
identifier digit
identifier-nondigit:
nondigit
universal-character-name
other implementation-defined characters
nondigit: one of
_ a b c d e f g h i j k l m
n o p q r s t u v w x y z
A B C D E F G H I J K L M
N O P Q R S T U V W X Y Z
digit: one of
0 1 2 3 4 5 6 7 8 9
You should restrict yourself to those.
Macro names should only consist of alphanumeric characters and underscores, i.e. 'a-z', 'A-Z', '0-9', and '_', and the first character should not be a digit. Some preprocessors also permit the dollar sign character '$', but you shouldn't use it.
Also have look on this... What are the valid characters for macro names?
It seems that
#define TE$T 8
is working, so$
is valid.
That's not true. $
is NOT a valid character for identifiers in standard C. Some compilers, e.g, GCC , allows $
in identifiers as an extension. (See Dollar Signs)
So you are asking the wrong question, there's nothing special for names in macros, all the preprocessor does is text replacement.

- 119,891
- 44
- 235
- 294
-
Wrong! It is not required by the standard, but the standard very well allows such additional characters, so for a specific implementation (e.g. gcc) they are very well valid characters. – too honest for this site Jun 01 '16 at 13:59
Consider somefille.c
#include<stdio.h>
#define NAM$ "SomeName"
int main(void)
{
printf("Name - %s\n",NAM$);
return 0;
}
Compiling the above with
gcc -pedantic somefille.c -o somefille
gives you
somefille.c:2:9: warning: '$' in identifier or number [enabled by default]
#define NAM$ "SomeName"
This [ page ] says.
-pedantic
Issue all the warnings demanded by strict ISO C and ISO C++; reject all programs that use forbidden extensions, and some other programs that do not follow ISO C and ISO C++. For ISO C, follows the version of the ISO C standard specified by any -std option used.
As per the strict standard the macro name must have no spaces in it, and it must conform to the same naming rules that C variables follow: Only letters, digits, and the underscore ( _ ) character can be used, and the first character cannot be a digit.
The problem is that various compilers do not comply with this. An example is gcc which I mentioned above.
Having said that, below rules are still obeyed:
A macro name must not begin with a number, if you violate this you may get an error like :
error: macro names must be identifiers
A macro name must not contain spaces. For instance
#define FULL NAME "Your name"
gives you :error: ‘NAME’ undeclared (first use in this function)

- 21,411
- 5
- 55
- 102
-
Wrong! It is not required by the standard, but the standard very well allows such additional characters, so for a specific implementation (e.g. gcc) they are very well valid characters (not specific for macro names, btw.). – too honest for this site Jun 01 '16 at 14:00
-
@Olaf : I did mention "strict ISO C" which doesn't allow anything other than standard features IMHO. – sjsam Jun 01 '16 at 15:32
-
Please read the cited paragraph carefully. The standard explicitly allows additional characters. Despite extensions which often violate the standard. – too honest for this site Jun 01 '16 at 17:51