Why prevents the use of âsi_â as prefix for the name of some variables?
Clash Royale CLAN TAG#URR8PPP
up vote
8
down vote
favorite
I have been debugging a strange compilation error that I was getting inside my code, and I ended up finding out that I cannot use the prefix si_
for some variable names (of any type) if <signal.h>
is included.
Here is a very simple source code example that reproduces the issue:
#include <signal.h>
int main(void)
int si_value = 0;
return 0;
If I try to compile this with the GNU C Compiler gcc
, I get the following error:
> gcc example.c
In file included from /usr/include/signal.h:57:0,
from example.c:2:
example.c: In function âÂÂmainâÂÂ:
example.c:6:9: error: expected âÂÂ=âÂÂ, âÂÂ,âÂÂ, âÂÂ;âÂÂ, âÂÂasmâ or âÂÂ__attribute__â before âÂÂ.â token
int si_value = 0;
^
example.c:6:9: error: expected expression before âÂÂ.â token
Nonetheless, if I use another name such as si_value2
, the error doesn't show up. As a reference, I'm using GCC v7.3.0 inside Ubuntu Mate 18.04.1 LTS. The same problem is observed with g++
.
I suppose that this behaviour is due to some macro definition inside the <signal.h>
header, but after going through it briefly, I couldn't seem to find anything really related.
I honestly can fix it by just using another name. However, my concern is: how could I elegantly avoid this type of issues in the future?
Thank you very much in advance and looking forward to learn from you all!
Update: As @F.X. has suggested, using gcc -E example.c
shows up that the variable name is expanded (hence, the error):
...
int
# 6 "example.c" 3 4
_sifields._rt.si_sigval
# 6 "example.c"
= 0;
...
c++ c linux
 |Â
show 5 more comments
up vote
8
down vote
favorite
I have been debugging a strange compilation error that I was getting inside my code, and I ended up finding out that I cannot use the prefix si_
for some variable names (of any type) if <signal.h>
is included.
Here is a very simple source code example that reproduces the issue:
#include <signal.h>
int main(void)
int si_value = 0;
return 0;
If I try to compile this with the GNU C Compiler gcc
, I get the following error:
> gcc example.c
In file included from /usr/include/signal.h:57:0,
from example.c:2:
example.c: In function âÂÂmainâÂÂ:
example.c:6:9: error: expected âÂÂ=âÂÂ, âÂÂ,âÂÂ, âÂÂ;âÂÂ, âÂÂasmâ or âÂÂ__attribute__â before âÂÂ.â token
int si_value = 0;
^
example.c:6:9: error: expected expression before âÂÂ.â token
Nonetheless, if I use another name such as si_value2
, the error doesn't show up. As a reference, I'm using GCC v7.3.0 inside Ubuntu Mate 18.04.1 LTS. The same problem is observed with g++
.
I suppose that this behaviour is due to some macro definition inside the <signal.h>
header, but after going through it briefly, I couldn't seem to find anything really related.
I honestly can fix it by just using another name. However, my concern is: how could I elegantly avoid this type of issues in the future?
Thank you very much in advance and looking forward to learn from you all!
Update: As @F.X. has suggested, using gcc -E example.c
shows up that the variable name is expanded (hence, the error):
...
int
# 6 "example.c" 3 4
_sifields._rt.si_sigval
# 6 "example.c"
= 0;
...
c++ c linux
3
Can you look at the output ofgcc -E
(right after preprocessor)? It might give you a hint as to what goes wrong.
â F.X.
55 mins ago
3
Is it just the namesi_value
? Smells like a macro is getting substituted into your code. What about something likesi_vy1ghad563nvy43wd
?
â alter igel
54 mins ago
2
@alterigel sorry,si_vy1ghad563nvy43wd
is also a reserved keyword.
â Jean-François Fabre
50 mins ago
2
@Jean-FrançoisFabre sorry,si_vy1ghad563nvy43wd
is also a reserved keyword Where is that a reserved keyword? If it exists, I can't find that in POSIX nor the C standard. Offhand, I don't even see howsi_value
fits into the POSIX "functions and external identifiers" reservation of identifiers.
â Andrew Henle
46 mins ago
2
@AndrewHenle okay this was a joke.
â Jean-François Fabre
45 mins ago
 |Â
show 5 more comments
up vote
8
down vote
favorite
up vote
8
down vote
favorite
I have been debugging a strange compilation error that I was getting inside my code, and I ended up finding out that I cannot use the prefix si_
for some variable names (of any type) if <signal.h>
is included.
Here is a very simple source code example that reproduces the issue:
#include <signal.h>
int main(void)
int si_value = 0;
return 0;
If I try to compile this with the GNU C Compiler gcc
, I get the following error:
> gcc example.c
In file included from /usr/include/signal.h:57:0,
from example.c:2:
example.c: In function âÂÂmainâÂÂ:
example.c:6:9: error: expected âÂÂ=âÂÂ, âÂÂ,âÂÂ, âÂÂ;âÂÂ, âÂÂasmâ or âÂÂ__attribute__â before âÂÂ.â token
int si_value = 0;
^
example.c:6:9: error: expected expression before âÂÂ.â token
Nonetheless, if I use another name such as si_value2
, the error doesn't show up. As a reference, I'm using GCC v7.3.0 inside Ubuntu Mate 18.04.1 LTS. The same problem is observed with g++
.
I suppose that this behaviour is due to some macro definition inside the <signal.h>
header, but after going through it briefly, I couldn't seem to find anything really related.
I honestly can fix it by just using another name. However, my concern is: how could I elegantly avoid this type of issues in the future?
Thank you very much in advance and looking forward to learn from you all!
Update: As @F.X. has suggested, using gcc -E example.c
shows up that the variable name is expanded (hence, the error):
...
int
# 6 "example.c" 3 4
_sifields._rt.si_sigval
# 6 "example.c"
= 0;
...
c++ c linux
I have been debugging a strange compilation error that I was getting inside my code, and I ended up finding out that I cannot use the prefix si_
for some variable names (of any type) if <signal.h>
is included.
Here is a very simple source code example that reproduces the issue:
#include <signal.h>
int main(void)
int si_value = 0;
return 0;
If I try to compile this with the GNU C Compiler gcc
, I get the following error:
> gcc example.c
In file included from /usr/include/signal.h:57:0,
from example.c:2:
example.c: In function âÂÂmainâÂÂ:
example.c:6:9: error: expected âÂÂ=âÂÂ, âÂÂ,âÂÂ, âÂÂ;âÂÂ, âÂÂasmâ or âÂÂ__attribute__â before âÂÂ.â token
int si_value = 0;
^
example.c:6:9: error: expected expression before âÂÂ.â token
Nonetheless, if I use another name such as si_value2
, the error doesn't show up. As a reference, I'm using GCC v7.3.0 inside Ubuntu Mate 18.04.1 LTS. The same problem is observed with g++
.
I suppose that this behaviour is due to some macro definition inside the <signal.h>
header, but after going through it briefly, I couldn't seem to find anything really related.
I honestly can fix it by just using another name. However, my concern is: how could I elegantly avoid this type of issues in the future?
Thank you very much in advance and looking forward to learn from you all!
Update: As @F.X. has suggested, using gcc -E example.c
shows up that the variable name is expanded (hence, the error):
...
int
# 6 "example.c" 3 4
_sifields._rt.si_sigval
# 6 "example.c"
= 0;
...
c++ c linux
c++ c linux
edited 7 mins ago
asked 57 mins ago
SRG
1029
1029
3
Can you look at the output ofgcc -E
(right after preprocessor)? It might give you a hint as to what goes wrong.
â F.X.
55 mins ago
3
Is it just the namesi_value
? Smells like a macro is getting substituted into your code. What about something likesi_vy1ghad563nvy43wd
?
â alter igel
54 mins ago
2
@alterigel sorry,si_vy1ghad563nvy43wd
is also a reserved keyword.
â Jean-François Fabre
50 mins ago
2
@Jean-FrançoisFabre sorry,si_vy1ghad563nvy43wd
is also a reserved keyword Where is that a reserved keyword? If it exists, I can't find that in POSIX nor the C standard. Offhand, I don't even see howsi_value
fits into the POSIX "functions and external identifiers" reservation of identifiers.
â Andrew Henle
46 mins ago
2
@AndrewHenle okay this was a joke.
â Jean-François Fabre
45 mins ago
 |Â
show 5 more comments
3
Can you look at the output ofgcc -E
(right after preprocessor)? It might give you a hint as to what goes wrong.
â F.X.
55 mins ago
3
Is it just the namesi_value
? Smells like a macro is getting substituted into your code. What about something likesi_vy1ghad563nvy43wd
?
â alter igel
54 mins ago
2
@alterigel sorry,si_vy1ghad563nvy43wd
is also a reserved keyword.
â Jean-François Fabre
50 mins ago
2
@Jean-FrançoisFabre sorry,si_vy1ghad563nvy43wd
is also a reserved keyword Where is that a reserved keyword? If it exists, I can't find that in POSIX nor the C standard. Offhand, I don't even see howsi_value
fits into the POSIX "functions and external identifiers" reservation of identifiers.
â Andrew Henle
46 mins ago
2
@AndrewHenle okay this was a joke.
â Jean-François Fabre
45 mins ago
3
3
Can you look at the output of
gcc -E
(right after preprocessor)? It might give you a hint as to what goes wrong.â F.X.
55 mins ago
Can you look at the output of
gcc -E
(right after preprocessor)? It might give you a hint as to what goes wrong.â F.X.
55 mins ago
3
3
Is it just the name
si_value
? Smells like a macro is getting substituted into your code. What about something like si_vy1ghad563nvy43wd
?â alter igel
54 mins ago
Is it just the name
si_value
? Smells like a macro is getting substituted into your code. What about something like si_vy1ghad563nvy43wd
?â alter igel
54 mins ago
2
2
@alterigel sorry,
si_vy1ghad563nvy43wd
is also a reserved keyword.â Jean-François Fabre
50 mins ago
@alterigel sorry,
si_vy1ghad563nvy43wd
is also a reserved keyword.â Jean-François Fabre
50 mins ago
2
2
@Jean-FrançoisFabre sorry,
si_vy1ghad563nvy43wd
is also a reserved keyword Where is that a reserved keyword? If it exists, I can't find that in POSIX nor the C standard. Offhand, I don't even see how si_value
fits into the POSIX "functions and external identifiers" reservation of identifiers.â Andrew Henle
46 mins ago
@Jean-FrançoisFabre sorry,
si_vy1ghad563nvy43wd
is also a reserved keyword Where is that a reserved keyword? If it exists, I can't find that in POSIX nor the C standard. Offhand, I don't even see how si_value
fits into the POSIX "functions and external identifiers" reservation of identifiers.â Andrew Henle
46 mins ago
2
2
@AndrewHenle okay this was a joke.
â Jean-François Fabre
45 mins ago
@AndrewHenle okay this was a joke.
â Jean-François Fabre
45 mins ago
 |Â
show 5 more comments
2 Answers
2
active
oldest
votes
up vote
5
down vote
accepted
<signal.h>
doesn't actually prevent using si_
as a prefix on your variables. However, the specification states that this prefix is reserved, in order to allow the header and the library functions that it declares to use these names, without having to worry that they'll conflict with your own variables.
So what's happening here is that si_value
is defined in some way in the header file, perhaps as a macro or typedef, and your attempt to use the same name conflicts with this. If you used si_vy1ghad563nvy43wd
it probably would work, but theoretically the header could use that name (thinking that it would be unlikely to conflict with anything an application programmer would use).
C doesn't have real namespaces, so naming conventions like this are used as a simple substitute.
Thank you Barmar, this answer is exactly what I was looking for!
â SRG
32 mins ago
1
Aren't identifiers starting with '__' reserved for the implementation? Can't it use that instead? Or is that something else?
â Kevin
9 mins ago
1
I think this is actually a POSIX thing, while__
is a C thing. So POSIX is trying to avoid names that are reserved to the C implementation.
â Barmar
4 mins ago
1
But isn'tsignal.h
a standard header?
â Kevin
2 mins ago
It may also be a backward compatibility issue --signal.h
had already been using lots ofsi_
names. Rather than list all these existing names as reserved, it just made the whole prefix reserved.
â Barmar
47 secs ago
add a comment |Â
up vote
7
down vote
how could I elegantly avoid this type of issues in the future?
You check some documentation for the headers you are using and avoid the names that are documented as reserved.
1
Where does it say thatsi_value
is a reserved name? All I see is references to a field of that name in thesiginfo_t
structure, but that's not at all the same thing?
â unwind
49 mins ago
@unwind, the prefixsi_
is reserved when using<signal.h>
â R Sahu
48 mins ago
1
@unwind 2.2.2 The namespace
â user463035818
48 mins ago
1
how can a prefix be reserved?
â Jean-François Fabre
47 mins ago
2
@Jean-FrançoisFabre Probably in the same manner they've reserved a_t
suffix
â VTT
45 mins ago
 |Â
show 4 more comments
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
5
down vote
accepted
<signal.h>
doesn't actually prevent using si_
as a prefix on your variables. However, the specification states that this prefix is reserved, in order to allow the header and the library functions that it declares to use these names, without having to worry that they'll conflict with your own variables.
So what's happening here is that si_value
is defined in some way in the header file, perhaps as a macro or typedef, and your attempt to use the same name conflicts with this. If you used si_vy1ghad563nvy43wd
it probably would work, but theoretically the header could use that name (thinking that it would be unlikely to conflict with anything an application programmer would use).
C doesn't have real namespaces, so naming conventions like this are used as a simple substitute.
Thank you Barmar, this answer is exactly what I was looking for!
â SRG
32 mins ago
1
Aren't identifiers starting with '__' reserved for the implementation? Can't it use that instead? Or is that something else?
â Kevin
9 mins ago
1
I think this is actually a POSIX thing, while__
is a C thing. So POSIX is trying to avoid names that are reserved to the C implementation.
â Barmar
4 mins ago
1
But isn'tsignal.h
a standard header?
â Kevin
2 mins ago
It may also be a backward compatibility issue --signal.h
had already been using lots ofsi_
names. Rather than list all these existing names as reserved, it just made the whole prefix reserved.
â Barmar
47 secs ago
add a comment |Â
up vote
5
down vote
accepted
<signal.h>
doesn't actually prevent using si_
as a prefix on your variables. However, the specification states that this prefix is reserved, in order to allow the header and the library functions that it declares to use these names, without having to worry that they'll conflict with your own variables.
So what's happening here is that si_value
is defined in some way in the header file, perhaps as a macro or typedef, and your attempt to use the same name conflicts with this. If you used si_vy1ghad563nvy43wd
it probably would work, but theoretically the header could use that name (thinking that it would be unlikely to conflict with anything an application programmer would use).
C doesn't have real namespaces, so naming conventions like this are used as a simple substitute.
Thank you Barmar, this answer is exactly what I was looking for!
â SRG
32 mins ago
1
Aren't identifiers starting with '__' reserved for the implementation? Can't it use that instead? Or is that something else?
â Kevin
9 mins ago
1
I think this is actually a POSIX thing, while__
is a C thing. So POSIX is trying to avoid names that are reserved to the C implementation.
â Barmar
4 mins ago
1
But isn'tsignal.h
a standard header?
â Kevin
2 mins ago
It may also be a backward compatibility issue --signal.h
had already been using lots ofsi_
names. Rather than list all these existing names as reserved, it just made the whole prefix reserved.
â Barmar
47 secs ago
add a comment |Â
up vote
5
down vote
accepted
up vote
5
down vote
accepted
<signal.h>
doesn't actually prevent using si_
as a prefix on your variables. However, the specification states that this prefix is reserved, in order to allow the header and the library functions that it declares to use these names, without having to worry that they'll conflict with your own variables.
So what's happening here is that si_value
is defined in some way in the header file, perhaps as a macro or typedef, and your attempt to use the same name conflicts with this. If you used si_vy1ghad563nvy43wd
it probably would work, but theoretically the header could use that name (thinking that it would be unlikely to conflict with anything an application programmer would use).
C doesn't have real namespaces, so naming conventions like this are used as a simple substitute.
<signal.h>
doesn't actually prevent using si_
as a prefix on your variables. However, the specification states that this prefix is reserved, in order to allow the header and the library functions that it declares to use these names, without having to worry that they'll conflict with your own variables.
So what's happening here is that si_value
is defined in some way in the header file, perhaps as a macro or typedef, and your attempt to use the same name conflicts with this. If you used si_vy1ghad563nvy43wd
it probably would work, but theoretically the header could use that name (thinking that it would be unlikely to conflict with anything an application programmer would use).
C doesn't have real namespaces, so naming conventions like this are used as a simple substitute.
answered 39 mins ago
Barmar
410k34235336
410k34235336
Thank you Barmar, this answer is exactly what I was looking for!
â SRG
32 mins ago
1
Aren't identifiers starting with '__' reserved for the implementation? Can't it use that instead? Or is that something else?
â Kevin
9 mins ago
1
I think this is actually a POSIX thing, while__
is a C thing. So POSIX is trying to avoid names that are reserved to the C implementation.
â Barmar
4 mins ago
1
But isn'tsignal.h
a standard header?
â Kevin
2 mins ago
It may also be a backward compatibility issue --signal.h
had already been using lots ofsi_
names. Rather than list all these existing names as reserved, it just made the whole prefix reserved.
â Barmar
47 secs ago
add a comment |Â
Thank you Barmar, this answer is exactly what I was looking for!
â SRG
32 mins ago
1
Aren't identifiers starting with '__' reserved for the implementation? Can't it use that instead? Or is that something else?
â Kevin
9 mins ago
1
I think this is actually a POSIX thing, while__
is a C thing. So POSIX is trying to avoid names that are reserved to the C implementation.
â Barmar
4 mins ago
1
But isn'tsignal.h
a standard header?
â Kevin
2 mins ago
It may also be a backward compatibility issue --signal.h
had already been using lots ofsi_
names. Rather than list all these existing names as reserved, it just made the whole prefix reserved.
â Barmar
47 secs ago
Thank you Barmar, this answer is exactly what I was looking for!
â SRG
32 mins ago
Thank you Barmar, this answer is exactly what I was looking for!
â SRG
32 mins ago
1
1
Aren't identifiers starting with '__' reserved for the implementation? Can't it use that instead? Or is that something else?
â Kevin
9 mins ago
Aren't identifiers starting with '__' reserved for the implementation? Can't it use that instead? Or is that something else?
â Kevin
9 mins ago
1
1
I think this is actually a POSIX thing, while
__
is a C thing. So POSIX is trying to avoid names that are reserved to the C implementation.â Barmar
4 mins ago
I think this is actually a POSIX thing, while
__
is a C thing. So POSIX is trying to avoid names that are reserved to the C implementation.â Barmar
4 mins ago
1
1
But isn't
signal.h
a standard header?â Kevin
2 mins ago
But isn't
signal.h
a standard header?â Kevin
2 mins ago
It may also be a backward compatibility issue --
signal.h
had already been using lots of si_
names. Rather than list all these existing names as reserved, it just made the whole prefix reserved.â Barmar
47 secs ago
It may also be a backward compatibility issue --
signal.h
had already been using lots of si_
names. Rather than list all these existing names as reserved, it just made the whole prefix reserved.â Barmar
47 secs ago
add a comment |Â
up vote
7
down vote
how could I elegantly avoid this type of issues in the future?
You check some documentation for the headers you are using and avoid the names that are documented as reserved.
1
Where does it say thatsi_value
is a reserved name? All I see is references to a field of that name in thesiginfo_t
structure, but that's not at all the same thing?
â unwind
49 mins ago
@unwind, the prefixsi_
is reserved when using<signal.h>
â R Sahu
48 mins ago
1
@unwind 2.2.2 The namespace
â user463035818
48 mins ago
1
how can a prefix be reserved?
â Jean-François Fabre
47 mins ago
2
@Jean-FrançoisFabre Probably in the same manner they've reserved a_t
suffix
â VTT
45 mins ago
 |Â
show 4 more comments
up vote
7
down vote
how could I elegantly avoid this type of issues in the future?
You check some documentation for the headers you are using and avoid the names that are documented as reserved.
1
Where does it say thatsi_value
is a reserved name? All I see is references to a field of that name in thesiginfo_t
structure, but that's not at all the same thing?
â unwind
49 mins ago
@unwind, the prefixsi_
is reserved when using<signal.h>
â R Sahu
48 mins ago
1
@unwind 2.2.2 The namespace
â user463035818
48 mins ago
1
how can a prefix be reserved?
â Jean-François Fabre
47 mins ago
2
@Jean-FrançoisFabre Probably in the same manner they've reserved a_t
suffix
â VTT
45 mins ago
 |Â
show 4 more comments
up vote
7
down vote
up vote
7
down vote
how could I elegantly avoid this type of issues in the future?
You check some documentation for the headers you are using and avoid the names that are documented as reserved.
how could I elegantly avoid this type of issues in the future?
You check some documentation for the headers you are using and avoid the names that are documented as reserved.
answered 53 mins ago
Baum mit Augen
39.8k12112145
39.8k12112145
1
Where does it say thatsi_value
is a reserved name? All I see is references to a field of that name in thesiginfo_t
structure, but that's not at all the same thing?
â unwind
49 mins ago
@unwind, the prefixsi_
is reserved when using<signal.h>
â R Sahu
48 mins ago
1
@unwind 2.2.2 The namespace
â user463035818
48 mins ago
1
how can a prefix be reserved?
â Jean-François Fabre
47 mins ago
2
@Jean-FrançoisFabre Probably in the same manner they've reserved a_t
suffix
â VTT
45 mins ago
 |Â
show 4 more comments
1
Where does it say thatsi_value
is a reserved name? All I see is references to a field of that name in thesiginfo_t
structure, but that's not at all the same thing?
â unwind
49 mins ago
@unwind, the prefixsi_
is reserved when using<signal.h>
â R Sahu
48 mins ago
1
@unwind 2.2.2 The namespace
â user463035818
48 mins ago
1
how can a prefix be reserved?
â Jean-François Fabre
47 mins ago
2
@Jean-FrançoisFabre Probably in the same manner they've reserved a_t
suffix
â VTT
45 mins ago
1
1
Where does it say that
si_value
is a reserved name? All I see is references to a field of that name in the siginfo_t
structure, but that's not at all the same thing?â unwind
49 mins ago
Where does it say that
si_value
is a reserved name? All I see is references to a field of that name in the siginfo_t
structure, but that's not at all the same thing?â unwind
49 mins ago
@unwind, the prefix
si_
is reserved when using <signal.h>
â R Sahu
48 mins ago
@unwind, the prefix
si_
is reserved when using <signal.h>
â R Sahu
48 mins ago
1
1
@unwind 2.2.2 The namespace
â user463035818
48 mins ago
@unwind 2.2.2 The namespace
â user463035818
48 mins ago
1
1
how can a prefix be reserved?
â Jean-François Fabre
47 mins ago
how can a prefix be reserved?
â Jean-François Fabre
47 mins ago
2
2
@Jean-FrançoisFabre Probably in the same manner they've reserved a
_t
suffixâ VTT
45 mins ago
@Jean-FrançoisFabre Probably in the same manner they've reserved a
_t
suffixâ VTT
45 mins ago
 |Â
show 4 more comments
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%2f53196962%2fwhy-signal-h-prevents-the-use-of-si-as-prefix-for-the-name-of-some-variable%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
3
Can you look at the output of
gcc -E
(right after preprocessor)? It might give you a hint as to what goes wrong.â F.X.
55 mins ago
3
Is it just the name
si_value
? Smells like a macro is getting substituted into your code. What about something likesi_vy1ghad563nvy43wd
?â alter igel
54 mins ago
2
@alterigel sorry,
si_vy1ghad563nvy43wd
is also a reserved keyword.â Jean-François Fabre
50 mins ago
2
@Jean-FrançoisFabre sorry,
si_vy1ghad563nvy43wd
is also a reserved keyword Where is that a reserved keyword? If it exists, I can't find that in POSIX nor the C standard. Offhand, I don't even see howsi_value
fits into the POSIX "functions and external identifiers" reservation of identifiers.â Andrew Henle
46 mins ago
2
@AndrewHenle okay this was a joke.
â Jean-François Fabre
45 mins ago