Reputation: 35448
I came to this obscure thing ... I would like to know if there are any possibilities for the @ sign to appear in the source of a valid C/C++ application, beside of the following situations:
const char*
value such as const char* addr = "[email protected]"
const char
value, such as char c = '@'
#define NEVER_EVER ABC@
Reason for asking: curiosity :)
Upvotes: 2
Views: 281
Reputation: 37954
I would answer for the C language. Note that there isn't any such thing as C/C++. Both are separate languages and C is not a subset of C++.
Beside those possibilities, that you described, @
can be also placed in header names, but it's not a common practice:
main.c:
#include <stdio.h>
#include "[email protected]"
int main(void)
{
foo();
return 0;
}
[email protected]:
static void foo(void)
{
printf("whatever\n");
}
For a Standard reference to cover this, you might look into C11 §5.2.1/p3 that covers the basic execution character set, which does not include the @
character. This paragraph also provides a list of cases that may allow a @
character (emphasis mine):
In the basic execution character set, there shall be control characters representing alert, backspace, carriage return, and new line. If any other characters are encountered in a source file (except in an identifier, a character constant, a string literal, a header name, a comment, or a preprocessing token that is never converted to a token), the behavior is undefined.
In case of identifiers, see C11 §6.4.2.1/p3:
Each universal character name in an identifier shall designate a character whose encoding in ISO/IEC 10646 falls into one of the ranges specified in D.1.71) The initial character shall not be a universal character name designating a character whose encoding falls into one of the ranges specified in D.2. An implementation may allow multibyte characters that are not part of the basic source character set to appear in identifiers; which characters and their correspondence to universal character names is implementation-defined.
The D.1 (normative) appendix section lists ranges of allowed characters. As you might check the @
character can be represented as U+0040
in UCS, that is outside of allowed range:
00A8, 00AA, 00AD, 00AF, 00B2−00B5, 00B7−00BA, 00BC−00BE, 00C0−00D6, 00D8−00F6, 00F8−00FF (...)
Even with that, compiler might allow @
character as language extension. C11 J.5.2/p1 Specialized identifiers (Common extensions) contains:
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).
For instance GCC allows $
sign as GNU extension in that way:
In GNU C, you may normally use dollar signs in identifier names. This is because many traditional C implementations allow such identifiers. However, dollar signs in identifiers are not supported on a few target machines, typically because the target assembler does not allow them.
Upvotes: 3
Reputation: 8333
There isn't any problem with all the above.
The @ is invalid in names (variables, functions, classes, etc.)
Some linkers actually use the @ character as "at" meaning to relate symbols to libraries. (try to nm
some of your executables in Linux);
you'll see something like this: malloc@@GLIBC_2.2.5
means malloc
taken from GLIBC_2.2.5.
In strings and characters, the only problematic seen character is the \
which is also used as an escape character and the "
in strings and '
in characters which must be escaped to not be translated as end of string/character.
In comments, there aren't any limitations except the */
in multi-line comment which will close the comment.
A never-used macro does not really exist after precompilation, so there isn't any problem at all.
Upvotes: 1