Mixing
What's the meaning of “reserved for any use�
Clash Royale CLAN TAG#URR8PPP
up vote
15
down vote
favorite
NOTE: This is a c question, though I added c++ in case some C++ expert can provide a rationale or historical reason why C++ is using a different wording than C.
In the C standard library specification, we have this normative text, C17 7.1.3 Reserved identifiers (emphasis mine):
- All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use.
- All identifiers that begin with an underscore are always reserved for use as identifiers with file scope in both the ordinary and tag name spaces.
Now I keep reading answers on SO by various esteemed C experts, where they claim it is fine for a compiler or standard library to use identifiers with underscore + uppercase, or double underscore.
Doesn't "reserved for any use" mean reserved for anyone except future extensions to the C language itself? Meaning that the implementation is not allowed to use them.
While the second phrase above, regarding single leading underscore seems to be directed to the implementation?
In general, the C standard is written in a way that expects compiler vendors/library implementers to be the typical reader - not so much the application programmers.
Notably, C++ has a very different wording:
- Each name that contains a double underscore (
__) or begins with an underscore followed by an uppercase letter (2.11) is reserved to the implementation for any use.
(See What are the rules about using an underscore in a C++ identifier?)
Is this perhaps a mix-up between C and C++ and the languages are different here?
c language-lawyer c-standard-library
edited 18 mins ago
too honest for this site
10.4k32347
asked 1 hour ago
Lundin
99.8k16145249
add a comment |Â
up vote
15
down vote
favorite
NOTE: This is a c question, though I added c++ in case some C++ expert can provide a rationale or historical reason why C++ is using a different wording than C.
In the C standard library specification, we have this normative text, C17 7.1.3 Reserved identifiers (emphasis mine):
- All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use.
- All identifiers that begin with an underscore are always reserved for use as identifiers with file scope in both the ordinary and tag name spaces.
Now I keep reading answers on SO by various esteemed C experts, where they claim it is fine for a compiler or standard library to use identifiers with underscore + uppercase, or double underscore.
Doesn't "reserved for any use" mean reserved for anyone except future extensions to the C language itself? Meaning that the implementation is not allowed to use them.
While the second phrase above, regarding single leading underscore seems to be directed to the implementation?
In general, the C standard is written in a way that expects compiler vendors/library implementers to be the typical reader - not so much the application programmers.
Notably, C++ has a very different wording:
- Each name that contains a double underscore (
__) or begins with an underscore followed by an uppercase letter (2.11) is reserved to the implementation for any use.
(See What are the rules about using an underscore in a C++ identifier?)
Is this perhaps a mix-up between C and C++ and the languages are different here?
c language-lawyer c-standard-library
edited 18 mins ago
too honest for this site
10.4k32347
asked 1 hour ago
Lundin
99.8k16145249
2
No namespace support in C. That makes life difficult for everybody. Including the ISO committee, they have to have a way to add an identifier without breaking the world.
– Hans Passant
48 mins ago
I'd say "reserved for any use" is for the implementation and standard library usage. Certainly the implementors of the library are expected to know the standard versions well enough to know the reserved names for each, so there is no name clash. Maybe this is meant to be extended to other system libraries, e.g. POSIX or Windows. But yes, I think missing custom namespaces are one reason for this floppy wording. I sometimes wish they would break "the world" of legacy code. That could still be compiled with the version it was designed for - or reworked. It works for e.g. Python.
– too honest for this site
12 mins ago
add a comment |Â
up vote
15
down vote
favorite
up vote
15
down vote
favorite
NOTE: This is a c question, though I added c++ in case some C++ expert can provide a rationale or historical reason why C++ is using a different wording than C.
In the C standard library specification, we have this normative text, C17 7.1.3 Reserved identifiers (emphasis mine):
- All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use.
- All identifiers that begin with an underscore are always reserved for use as identifiers with file scope in both the ordinary and tag name spaces.
Now I keep reading answers on SO by various esteemed C experts, where they claim it is fine for a compiler or standard library to use identifiers with underscore + uppercase, or double underscore.
Doesn't "reserved for any use" mean reserved for anyone except future extensions to the C language itself? Meaning that the implementation is not allowed to use them.
While the second phrase above, regarding single leading underscore seems to be directed to the implementation?
In general, the C standard is written in a way that expects compiler vendors/library implementers to be the typical reader - not so much the application programmers.
Notably, C++ has a very different wording:
- Each name that contains a double underscore (
__) or begins with an underscore followed by an uppercase letter (2.11) is reserved to the implementation for any use.
(See What are the rules about using an underscore in a C++ identifier?)
Is this perhaps a mix-up between C and C++ and the languages are different here?
c language-lawyer c-standard-library
edited 18 mins ago
too honest for this site
10.4k32347
asked 1 hour ago
Lundin
99.8k16145249
NOTE: This is a c question, though I added c++ in case some C++ expert can provide a rationale or historical reason why C++ is using a different wording than C.
In the C standard library specification, we have this normative text, C17 7.1.3 Reserved identifiers (emphasis mine):
- All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use.
- All identifiers that begin with an underscore are always reserved for use as identifiers with file scope in both the ordinary and tag name spaces.
Now I keep reading answers on SO by various esteemed C experts, where they claim it is fine for a compiler or standard library to use identifiers with underscore + uppercase, or double underscore.
Doesn't "reserved for any use" mean reserved for anyone except future extensions to the C language itself? Meaning that the implementation is not allowed to use them.
While the second phrase above, regarding single leading underscore seems to be directed to the implementation?
In general, the C standard is written in a way that expects compiler vendors/library implementers to be the typical reader - not so much the application programmers.
Notably, C++ has a very different wording:
- Each name that contains a double underscore (
__) or begins with an underscore followed by an uppercase letter (2.11) is reserved to the implementation for any use.
(See What are the rules about using an underscore in a C++ identifier?)
Is this perhaps a mix-up between C and C++ and the languages are different here?
c language-lawyer c-standard-library
c language-lawyer c-standard-library
edited 18 mins ago
too honest for this site
10.4k32347
asked 1 hour ago
Lundin
99.8k16145249
edited 18 mins ago
too honest for this site
10.4k32347
asked 1 hour ago
Lundin
99.8k16145249
edited 18 mins ago
too honest for this site
10.4k32347
edited 18 mins ago
too honest for this site
10.4k32347
edited 18 mins ago
too honest for this site
10.4k32347
10.4k32347
asked 1 hour ago
Lundin
99.8k16145249
asked 1 hour ago
Lundin
99.8k16145249
asked 1 hour ago
Lundin
99.8k16145249
99.8k16145249
2
No namespace support in C. That makes life difficult for everybody. Including the ISO committee, they have to have a way to add an identifier without breaking the world.
– Hans Passant
48 mins ago
I'd say "reserved for any use" is for the implementation and standard library usage. Certainly the implementors of the library are expected to know the standard versions well enough to know the reserved names for each, so there is no name clash. Maybe this is meant to be extended to other system libraries, e.g. POSIX or Windows. But yes, I think missing custom namespaces are one reason for this floppy wording. I sometimes wish they would break "the world" of legacy code. That could still be compiled with the version it was designed for - or reworked. It works for e.g. Python.
– too honest for this site
12 mins ago
add a comment |Â
2
No namespace support in C. That makes life difficult for everybody. Including the ISO committee, they have to have a way to add an identifier without breaking the world.
– Hans Passant
48 mins ago
I'd say "reserved for any use" is for the implementation and standard library usage. Certainly the implementors of the library are expected to know the standard versions well enough to know the reserved names for each, so there is no name clash. Maybe this is meant to be extended to other system libraries, e.g. POSIX or Windows. But yes, I think missing custom namespaces are one reason for this floppy wording. I sometimes wish they would break "the world" of legacy code. That could still be compiled with the version it was designed for - or reworked. It works for e.g. Python.
– too honest for this site
12 mins ago
2
2
No namespace support in C. That makes life difficult for everybody. Including the ISO committee, they have to have a way to add an identifier without breaking the world.
– Hans Passant
48 mins ago
No namespace support in C. That makes life difficult for everybody. Including the ISO committee, they have to have a way to add an identifier without breaking the world.
– Hans Passant
48 mins ago
I'd say "reserved for any use" is for the implementation and standard library usage. Certainly the implementors of the library are expected to know the standard versions well enough to know the reserved names for each, so there is no name clash. Maybe this is meant to be extended to other system libraries, e.g. POSIX or Windows. But yes, I think missing custom namespaces are one reason for this floppy wording. I sometimes wish they would break "the world" of legacy code. That could still be compiled with the version it was designed for - or reworked. It works for e.g. Python.
– too honest for this site
12 mins ago
I'd say "reserved for any use" is for the implementation and standard library usage. Certainly the implementors of the library are expected to know the standard versions well enough to know the reserved names for each, so there is no name clash. Maybe this is meant to be extended to other system libraries, e.g. POSIX or Windows. But yes, I think missing custom namespaces are one reason for this floppy wording. I sometimes wish they would break "the world" of legacy code. That could still be compiled with the version it was designed for - or reworked. It works for e.g. Python.
– too honest for this site
12 mins ago
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
11
down vote
In the C standard, the meaning of the term "reserved" is defined by 7.1.3p2, immediately below the bullet list you are quoting:
No other identifiers are reserved. If the program declares or defines an identifier in a context in which it is reserved (other than as allowed by 7.1.4), or defines a reserved identifier as a macro name, the behavior is undefined.
Emphasis mine: reserved identifiers place a restriction on the program, not the implementation. Thus, the common interpretation -- reserved identifiers may be used by the implementation to any purpose -- is correct for C.
I have not kept up with the C++ standard and no longer feel qualified to interpret it.
answered 53 mins ago
zwol
93.8k23159258
add a comment |Â
up vote
-1
down vote
If I had to guess the reason for the expanded double underscore restriction in C++, I'd have to say it may be due to CFront. Since it translated C++ into C, the way it "mangled" names was by... adding double underscores (and other tokens) between source tokens. That is a way to produce valid C identifiers in the generated C code, while making sure they won't clash with anything the C++ source code defines.
I base that assumption on the source code of CFront 3.0.3 (courtesy of the software preservation project). For instance, here's how it mangled a function template:
char*
funct_inst::mangled_name(char *ip)
{ /* generate mangled template instantiation name of the form
* <function_name>__pt__F<size>_[<arg>_]... */
So a template function foo in the C++ source would result in foo__pt__F<more stuff> in the generated C code.
I imagine that when standardization came about, that restriction was kept in order to preserve existing implementations of C++.
answered 18 mins ago
StoryTeller
83k12166230
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
11
down vote
In the C standard, the meaning of the term "reserved" is defined by 7.1.3p2, immediately below the bullet list you are quoting:
No other identifiers are reserved. If the program declares or defines an identifier in a context in which it is reserved (other than as allowed by 7.1.4), or defines a reserved identifier as a macro name, the behavior is undefined.
Emphasis mine: reserved identifiers place a restriction on the program, not the implementation. Thus, the common interpretation -- reserved identifiers may be used by the implementation to any purpose -- is correct for C.
I have not kept up with the C++ standard and no longer feel qualified to interpret it.
answered 53 mins ago
zwol
93.8k23159258
add a comment |Â
up vote
11
down vote
In the C standard, the meaning of the term "reserved" is defined by 7.1.3p2, immediately below the bullet list you are quoting:
No other identifiers are reserved. If the program declares or defines an identifier in a context in which it is reserved (other than as allowed by 7.1.4), or defines a reserved identifier as a macro name, the behavior is undefined.
Emphasis mine: reserved identifiers place a restriction on the program, not the implementation. Thus, the common interpretation -- reserved identifiers may be used by the implementation to any purpose -- is correct for C.
I have not kept up with the C++ standard and no longer feel qualified to interpret it.
answered 53 mins ago
zwol
93.8k23159258
add a comment |Â
up vote
11
down vote
up vote
11
down vote
In the C standard, the meaning of the term "reserved" is defined by 7.1.3p2, immediately below the bullet list you are quoting:
No other identifiers are reserved. If the program declares or defines an identifier in a context in which it is reserved (other than as allowed by 7.1.4), or defines a reserved identifier as a macro name, the behavior is undefined.
Emphasis mine: reserved identifiers place a restriction on the program, not the implementation. Thus, the common interpretation -- reserved identifiers may be used by the implementation to any purpose -- is correct for C.
I have not kept up with the C++ standard and no longer feel qualified to interpret it.
answered 53 mins ago
zwol
93.8k23159258
In the C standard, the meaning of the term "reserved" is defined by 7.1.3p2, immediately below the bullet list you are quoting:
No other identifiers are reserved. If the program declares or defines an identifier in a context in which it is reserved (other than as allowed by 7.1.4), or defines a reserved identifier as a macro name, the behavior is undefined.
Emphasis mine: reserved identifiers place a restriction on the program, not the implementation. Thus, the common interpretation -- reserved identifiers may be used by the implementation to any purpose -- is correct for C.
I have not kept up with the C++ standard and no longer feel qualified to interpret it.
answered 53 mins ago
zwol
93.8k23159258
answered 53 mins ago
zwol
93.8k23159258
answered 53 mins ago
zwol
93.8k23159258
answered 53 mins ago
zwol
93.8k23159258
93.8k23159258
add a comment |Â
add a comment |Â
up vote
-1
down vote
If I had to guess the reason for the expanded double underscore restriction in C++, I'd have to say it may be due to CFront. Since it translated C++ into C, the way it "mangled" names was by... adding double underscores (and other tokens) between source tokens. That is a way to produce valid C identifiers in the generated C code, while making sure they won't clash with anything the C++ source code defines.
I base that assumption on the source code of CFront 3.0.3 (courtesy of the software preservation project). For instance, here's how it mangled a function template:
char*
funct_inst::mangled_name(char *ip)
{ /* generate mangled template instantiation name of the form
* <function_name>__pt__F<size>_[<arg>_]... */
So a template function foo in the C++ source would result in foo__pt__F<more stuff> in the generated C code.
I imagine that when standardization came about, that restriction was kept in order to preserve existing implementations of C++.
answered 18 mins ago
StoryTeller
83k12166230
add a comment |Â
up vote
-1
down vote
If I had to guess the reason for the expanded double underscore restriction in C++, I'd have to say it may be due to CFront. Since it translated C++ into C, the way it "mangled" names was by... adding double underscores (and other tokens) between source tokens. That is a way to produce valid C identifiers in the generated C code, while making sure they won't clash with anything the C++ source code defines.
I base that assumption on the source code of CFront 3.0.3 (courtesy of the software preservation project). For instance, here's how it mangled a function template:
char*
funct_inst::mangled_name(char *ip)
{ /* generate mangled template instantiation name of the form
* <function_name>__pt__F<size>_[<arg>_]... */
So a template function foo in the C++ source would result in foo__pt__F<more stuff> in the generated C code.
I imagine that when standardization came about, that restriction was kept in order to preserve existing implementations of C++.
answered 18 mins ago
StoryTeller
83k12166230
add a comment |Â
up vote
-1
down vote
up vote
-1
down vote
If I had to guess the reason for the expanded double underscore restriction in C++, I'd have to say it may be due to CFront. Since it translated C++ into C, the way it "mangled" names was by... adding double underscores (and other tokens) between source tokens. That is a way to produce valid C identifiers in the generated C code, while making sure they won't clash with anything the C++ source code defines.
I base that assumption on the source code of CFront 3.0.3 (courtesy of the software preservation project). For instance, here's how it mangled a function template:
char*
funct_inst::mangled_name(char *ip)
{ /* generate mangled template instantiation name of the form
* <function_name>__pt__F<size>_[<arg>_]... */
So a template function foo in the C++ source would result in foo__pt__F<more stuff> in the generated C code.
I imagine that when standardization came about, that restriction was kept in order to preserve existing implementations of C++.
answered 18 mins ago
StoryTeller
83k12166230
If I had to guess the reason for the expanded double underscore restriction in C++, I'd have to say it may be due to CFront. Since it translated C++ into C, the way it "mangled" names was by... adding double underscores (and other tokens) between source tokens. That is a way to produce valid C identifiers in the generated C code, while making sure they won't clash with anything the C++ source code defines.
I base that assumption on the source code of CFront 3.0.3 (courtesy of the software preservation project). For instance, here's how it mangled a function template:
char*
funct_inst::mangled_name(char *ip)
{ /* generate mangled template instantiation name of the form
* <function_name>__pt__F<size>_[<arg>_]... */
So a template function foo in the C++ source would result in foo__pt__F<more stuff> in the generated C code.
I imagine that when standardization came about, that restriction was kept in order to preserve existing implementations of C++.
answered 18 mins ago
StoryTeller
83k12166230
edited 13 mins ago
answered 18 mins ago
StoryTeller
83k12166230
answered 18 mins ago
StoryTeller
83k12166230
answered 18 mins ago
StoryTeller
83k12166230
83k12166230
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f52367490%2fwhats-the-meaning-of-reserved-for-any-use%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
2
No namespace support in C. That makes life difficult for everybody. Including the ISO committee, they have to have a way to add an identifier without breaking the world.
– Hans Passant
48 mins ago
I'd say "reserved for any use" is for the implementation and standard library usage. Certainly the implementors of the library are expected to know the standard versions well enough to know the reserved names for each, so there is no name clash. Maybe this is meant to be extended to other system libraries, e.g. POSIX or Windows. But yes, I think missing custom namespaces are one reason for this floppy wording. I sometimes wish they would break "the world" of legacy code. That could still be compiled with the version it was designed for - or reworked. It works for e.g. Python.
– too honest for this site
12 mins ago