Why does prevent the use of “si_” as prefix for the name of some variables?
up vote
21
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 on 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 issue in the future?
Update: As @F.X. has suggested, using gcc -E example.c
shows 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 8 more comments
up vote
21
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 on 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 issue in the future?
Update: As @F.X. has suggested, using gcc -E example.c
shows 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
5
Can you look at the output ofgcc -E
(right after preprocessor)? It might give you a hint as to what goes wrong.
– F.X.
Nov 7 at 20:03
4
Is it just the namesi_value
? Smells like a macro is getting substituted into your code. What about something likesi_vy1ghad563nvy43wd
?
– alter igel
Nov 7 at 20:05
3
@alterigel sorry,si_vy1ghad563nvy43wd
is also a reserved keyword.
– Jean-François Fabre
Nov 7 at 20:08
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
Nov 7 at 20:13
3
@AndrewHenle okay this was a joke.
– Jean-François Fabre
Nov 7 at 20:13
|
show 8 more comments
up vote
21
down vote
favorite
up vote
21
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 on 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 issue in the future?
Update: As @F.X. has suggested, using gcc -E example.c
shows 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 on 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 issue in the future?
Update: As @F.X. has suggested, using gcc -E example.c
shows 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 Nov 7 at 22:10
Boann
36.4k1286119
36.4k1286119
asked Nov 7 at 20:01
SRG
181112
181112
5
Can you look at the output ofgcc -E
(right after preprocessor)? It might give you a hint as to what goes wrong.
– F.X.
Nov 7 at 20:03
4
Is it just the namesi_value
? Smells like a macro is getting substituted into your code. What about something likesi_vy1ghad563nvy43wd
?
– alter igel
Nov 7 at 20:05
3
@alterigel sorry,si_vy1ghad563nvy43wd
is also a reserved keyword.
– Jean-François Fabre
Nov 7 at 20:08
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
Nov 7 at 20:13
3
@AndrewHenle okay this was a joke.
– Jean-François Fabre
Nov 7 at 20:13
|
show 8 more comments
5
Can you look at the output ofgcc -E
(right after preprocessor)? It might give you a hint as to what goes wrong.
– F.X.
Nov 7 at 20:03
4
Is it just the namesi_value
? Smells like a macro is getting substituted into your code. What about something likesi_vy1ghad563nvy43wd
?
– alter igel
Nov 7 at 20:05
3
@alterigel sorry,si_vy1ghad563nvy43wd
is also a reserved keyword.
– Jean-François Fabre
Nov 7 at 20:08
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
Nov 7 at 20:13
3
@AndrewHenle okay this was a joke.
– Jean-François Fabre
Nov 7 at 20:13
5
5
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.
Nov 7 at 20:03
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.
Nov 7 at 20:03
4
4
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
Nov 7 at 20:05
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
Nov 7 at 20:05
3
3
@alterigel sorry,
si_vy1ghad563nvy43wd
is also a reserved keyword.– Jean-François Fabre
Nov 7 at 20:08
@alterigel sorry,
si_vy1ghad563nvy43wd
is also a reserved keyword.– Jean-François Fabre
Nov 7 at 20:08
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
Nov 7 at 20:13
@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
Nov 7 at 20:13
3
3
@AndrewHenle okay this was a joke.
– Jean-François Fabre
Nov 7 at 20:13
@AndrewHenle okay this was a joke.
– Jean-François Fabre
Nov 7 at 20:13
|
show 8 more comments
2 Answers
2
active
oldest
votes
up vote
21
down vote
accepted
<signal.h>
doesn't actually prevent using si_
as a prefix on your variables. However, the POSIX 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.
1
Aren't identifiers starting with '__' reserved for the implementation? Can't it use that instead? Or is that something else?
– Kevin
Nov 7 at 20:50
3
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
Nov 7 at 20:55
1
But isn'tsignal.h
a standard header?
– Kevin
Nov 7 at 20:56
3
C11 reserves names startingSIG
followed by a capital letter, orSIG_
followed by a capital letter (C11 §7.14 Signal handling<signal.h>
). POSIX reserves a lot more symbol prefixes when<signal.h>
is included — §2.2.2 The Name Space. The C standard reserves leading__
for use by the implementation (C11 §7.1.3 Reserved identifiers). Read and take care to avoid conflicts. Or fix 'em when they arise.
– Jonathan Leffler
Nov 7 at 21:01
2
@Kevin: The<signal.h>
header is both a standard C header and a standard POSIX header. Since you didn't specify-std=c11
or similar when you invoked GCC, it enabled all the GNU extensions, which includes the POSIX functions and symbols. If you specified-std=c11
, you might need to write-D_XOPEN_SOURCE=700
on the compiler command line, or a similar#define
in a header or your code (I recommend doing it in a header, having used it in code once upon a decade ago, and having spent a fair amount of time undoing it since then).
– Jonathan Leffler
Nov 7 at 21:04
|
show 6 more comments
up vote
12
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
Nov 7 at 20:10
1
@unwind 2.2.2 The namespace
– user463035818
Nov 7 at 20:11
1
how can a prefix be reserved?
– Jean-François Fabre
Nov 7 at 20:12
4
@Jean-FrançoisFabre Probably in the same manner they've reserved a_t
suffix
– VTT
Nov 7 at 20:14
4
@SRG No worries; your vote, your judgement, that's by design.
– Baum mit Augen
Nov 7 at 22:04
|
show 5 more comments
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
21
down vote
accepted
<signal.h>
doesn't actually prevent using si_
as a prefix on your variables. However, the POSIX 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.
1
Aren't identifiers starting with '__' reserved for the implementation? Can't it use that instead? Or is that something else?
– Kevin
Nov 7 at 20:50
3
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
Nov 7 at 20:55
1
But isn'tsignal.h
a standard header?
– Kevin
Nov 7 at 20:56
3
C11 reserves names startingSIG
followed by a capital letter, orSIG_
followed by a capital letter (C11 §7.14 Signal handling<signal.h>
). POSIX reserves a lot more symbol prefixes when<signal.h>
is included — §2.2.2 The Name Space. The C standard reserves leading__
for use by the implementation (C11 §7.1.3 Reserved identifiers). Read and take care to avoid conflicts. Or fix 'em when they arise.
– Jonathan Leffler
Nov 7 at 21:01
2
@Kevin: The<signal.h>
header is both a standard C header and a standard POSIX header. Since you didn't specify-std=c11
or similar when you invoked GCC, it enabled all the GNU extensions, which includes the POSIX functions and symbols. If you specified-std=c11
, you might need to write-D_XOPEN_SOURCE=700
on the compiler command line, or a similar#define
in a header or your code (I recommend doing it in a header, having used it in code once upon a decade ago, and having spent a fair amount of time undoing it since then).
– Jonathan Leffler
Nov 7 at 21:04
|
show 6 more comments
up vote
21
down vote
accepted
<signal.h>
doesn't actually prevent using si_
as a prefix on your variables. However, the POSIX 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.
1
Aren't identifiers starting with '__' reserved for the implementation? Can't it use that instead? Or is that something else?
– Kevin
Nov 7 at 20:50
3
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
Nov 7 at 20:55
1
But isn'tsignal.h
a standard header?
– Kevin
Nov 7 at 20:56
3
C11 reserves names startingSIG
followed by a capital letter, orSIG_
followed by a capital letter (C11 §7.14 Signal handling<signal.h>
). POSIX reserves a lot more symbol prefixes when<signal.h>
is included — §2.2.2 The Name Space. The C standard reserves leading__
for use by the implementation (C11 §7.1.3 Reserved identifiers). Read and take care to avoid conflicts. Or fix 'em when they arise.
– Jonathan Leffler
Nov 7 at 21:01
2
@Kevin: The<signal.h>
header is both a standard C header and a standard POSIX header. Since you didn't specify-std=c11
or similar when you invoked GCC, it enabled all the GNU extensions, which includes the POSIX functions and symbols. If you specified-std=c11
, you might need to write-D_XOPEN_SOURCE=700
on the compiler command line, or a similar#define
in a header or your code (I recommend doing it in a header, having used it in code once upon a decade ago, and having spent a fair amount of time undoing it since then).
– Jonathan Leffler
Nov 7 at 21:04
|
show 6 more comments
up vote
21
down vote
accepted
up vote
21
down vote
accepted
<signal.h>
doesn't actually prevent using si_
as a prefix on your variables. However, the POSIX 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 POSIX 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.
edited Nov 7 at 21:06
Jonathan Leffler
553k876571009
553k876571009
answered Nov 7 at 20:20
Barmar
411k34235337
411k34235337
1
Aren't identifiers starting with '__' reserved for the implementation? Can't it use that instead? Or is that something else?
– Kevin
Nov 7 at 20:50
3
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
Nov 7 at 20:55
1
But isn'tsignal.h
a standard header?
– Kevin
Nov 7 at 20:56
3
C11 reserves names startingSIG
followed by a capital letter, orSIG_
followed by a capital letter (C11 §7.14 Signal handling<signal.h>
). POSIX reserves a lot more symbol prefixes when<signal.h>
is included — §2.2.2 The Name Space. The C standard reserves leading__
for use by the implementation (C11 §7.1.3 Reserved identifiers). Read and take care to avoid conflicts. Or fix 'em when they arise.
– Jonathan Leffler
Nov 7 at 21:01
2
@Kevin: The<signal.h>
header is both a standard C header and a standard POSIX header. Since you didn't specify-std=c11
or similar when you invoked GCC, it enabled all the GNU extensions, which includes the POSIX functions and symbols. If you specified-std=c11
, you might need to write-D_XOPEN_SOURCE=700
on the compiler command line, or a similar#define
in a header or your code (I recommend doing it in a header, having used it in code once upon a decade ago, and having spent a fair amount of time undoing it since then).
– Jonathan Leffler
Nov 7 at 21:04
|
show 6 more comments
1
Aren't identifiers starting with '__' reserved for the implementation? Can't it use that instead? Or is that something else?
– Kevin
Nov 7 at 20:50
3
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
Nov 7 at 20:55
1
But isn'tsignal.h
a standard header?
– Kevin
Nov 7 at 20:56
3
C11 reserves names startingSIG
followed by a capital letter, orSIG_
followed by a capital letter (C11 §7.14 Signal handling<signal.h>
). POSIX reserves a lot more symbol prefixes when<signal.h>
is included — §2.2.2 The Name Space. The C standard reserves leading__
for use by the implementation (C11 §7.1.3 Reserved identifiers). Read and take care to avoid conflicts. Or fix 'em when they arise.
– Jonathan Leffler
Nov 7 at 21:01
2
@Kevin: The<signal.h>
header is both a standard C header and a standard POSIX header. Since you didn't specify-std=c11
or similar when you invoked GCC, it enabled all the GNU extensions, which includes the POSIX functions and symbols. If you specified-std=c11
, you might need to write-D_XOPEN_SOURCE=700
on the compiler command line, or a similar#define
in a header or your code (I recommend doing it in a header, having used it in code once upon a decade ago, and having spent a fair amount of time undoing it since then).
– Jonathan Leffler
Nov 7 at 21:04
1
1
Aren't identifiers starting with '__' reserved for the implementation? Can't it use that instead? Or is that something else?
– Kevin
Nov 7 at 20:50
Aren't identifiers starting with '__' reserved for the implementation? Can't it use that instead? Or is that something else?
– Kevin
Nov 7 at 20:50
3
3
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
Nov 7 at 20:55
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
Nov 7 at 20:55
1
1
But isn't
signal.h
a standard header?– Kevin
Nov 7 at 20:56
But isn't
signal.h
a standard header?– Kevin
Nov 7 at 20:56
3
3
C11 reserves names starting
SIG
followed by a capital letter, or SIG_
followed by a capital letter (C11 §7.14 Signal handling <signal.h>
). POSIX reserves a lot more symbol prefixes when <signal.h>
is included — §2.2.2 The Name Space. The C standard reserves leading __
for use by the implementation (C11 §7.1.3 Reserved identifiers). Read and take care to avoid conflicts. Or fix 'em when they arise.– Jonathan Leffler
Nov 7 at 21:01
C11 reserves names starting
SIG
followed by a capital letter, or SIG_
followed by a capital letter (C11 §7.14 Signal handling <signal.h>
). POSIX reserves a lot more symbol prefixes when <signal.h>
is included — §2.2.2 The Name Space. The C standard reserves leading __
for use by the implementation (C11 §7.1.3 Reserved identifiers). Read and take care to avoid conflicts. Or fix 'em when they arise.– Jonathan Leffler
Nov 7 at 21:01
2
2
@Kevin: The
<signal.h>
header is both a standard C header and a standard POSIX header. Since you didn't specify -std=c11
or similar when you invoked GCC, it enabled all the GNU extensions, which includes the POSIX functions and symbols. If you specified -std=c11
, you might need to write -D_XOPEN_SOURCE=700
on the compiler command line, or a similar #define
in a header or your code (I recommend doing it in a header, having used it in code once upon a decade ago, and having spent a fair amount of time undoing it since then).– Jonathan Leffler
Nov 7 at 21:04
@Kevin: The
<signal.h>
header is both a standard C header and a standard POSIX header. Since you didn't specify -std=c11
or similar when you invoked GCC, it enabled all the GNU extensions, which includes the POSIX functions and symbols. If you specified -std=c11
, you might need to write -D_XOPEN_SOURCE=700
on the compiler command line, or a similar #define
in a header or your code (I recommend doing it in a header, having used it in code once upon a decade ago, and having spent a fair amount of time undoing it since then).– Jonathan Leffler
Nov 7 at 21:04
|
show 6 more comments
up vote
12
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
Nov 7 at 20:10
1
@unwind 2.2.2 The namespace
– user463035818
Nov 7 at 20:11
1
how can a prefix be reserved?
– Jean-François Fabre
Nov 7 at 20:12
4
@Jean-FrançoisFabre Probably in the same manner they've reserved a_t
suffix
– VTT
Nov 7 at 20:14
4
@SRG No worries; your vote, your judgement, that's by design.
– Baum mit Augen
Nov 7 at 22:04
|
show 5 more comments
up vote
12
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
Nov 7 at 20:10
1
@unwind 2.2.2 The namespace
– user463035818
Nov 7 at 20:11
1
how can a prefix be reserved?
– Jean-François Fabre
Nov 7 at 20:12
4
@Jean-FrançoisFabre Probably in the same manner they've reserved a_t
suffix
– VTT
Nov 7 at 20:14
4
@SRG No worries; your vote, your judgement, that's by design.
– Baum mit Augen
Nov 7 at 22:04
|
show 5 more comments
up vote
12
down vote
up vote
12
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 Nov 7 at 20:06
Baum mit Augen
39.9k12112146
39.9k12112146
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
Nov 7 at 20:10
1
@unwind 2.2.2 The namespace
– user463035818
Nov 7 at 20:11
1
how can a prefix be reserved?
– Jean-François Fabre
Nov 7 at 20:12
4
@Jean-FrançoisFabre Probably in the same manner they've reserved a_t
suffix
– VTT
Nov 7 at 20:14
4
@SRG No worries; your vote, your judgement, that's by design.
– Baum mit Augen
Nov 7 at 22:04
|
show 5 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
Nov 7 at 20:10
1
@unwind 2.2.2 The namespace
– user463035818
Nov 7 at 20:11
1
how can a prefix be reserved?
– Jean-François Fabre
Nov 7 at 20:12
4
@Jean-FrançoisFabre Probably in the same manner they've reserved a_t
suffix
– VTT
Nov 7 at 20:14
4
@SRG No worries; your vote, your judgement, that's by design.
– Baum mit Augen
Nov 7 at 22:04
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
Nov 7 at 20:10
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
Nov 7 at 20:10
1
1
@unwind 2.2.2 The namespace
– user463035818
Nov 7 at 20:11
@unwind 2.2.2 The namespace
– user463035818
Nov 7 at 20:11
1
1
how can a prefix be reserved?
– Jean-François Fabre
Nov 7 at 20:12
how can a prefix be reserved?
– Jean-François Fabre
Nov 7 at 20:12
4
4
@Jean-FrançoisFabre Probably in the same manner they've reserved a
_t
suffix– VTT
Nov 7 at 20:14
@Jean-FrançoisFabre Probably in the same manner they've reserved a
_t
suffix– VTT
Nov 7 at 20:14
4
4
@SRG No worries; your vote, your judgement, that's by design.
– Baum mit Augen
Nov 7 at 22:04
@SRG No worries; your vote, your judgement, that's by design.
– Baum mit Augen
Nov 7 at 22:04
|
show 5 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-does-signal-h-prevent-the-use-of-si-as-prefix-for-the-name-of-some-vari%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
5
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.
Nov 7 at 20:03
4
Is it just the name
si_value
? Smells like a macro is getting substituted into your code. What about something likesi_vy1ghad563nvy43wd
?– alter igel
Nov 7 at 20:05
3
@alterigel sorry,
si_vy1ghad563nvy43wd
is also a reserved keyword.– Jean-François Fabre
Nov 7 at 20:08
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
Nov 7 at 20:13
3
@AndrewHenle okay this was a joke.
– Jean-François Fabre
Nov 7 at 20:13