Why prevents the use of “si_” as prefix for the name of some variables?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
8
down vote

favorite
1












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;
...









share|improve this question



















  • 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 like si_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 how si_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














up vote
8
down vote

favorite
1












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;
...









share|improve this question



















  • 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 like si_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 how si_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












up vote
8
down vote

favorite
1









up vote
8
down vote

favorite
1






1





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;
...









share|improve this question















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 7 mins ago

























asked 57 mins ago









SRG

1029




1029







  • 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 like si_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 how si_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




    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 like si_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 how si_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












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.






share|improve this answer




















  • 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'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

















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.






share|improve this answer
















  • 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










  • @unwind, the prefix si_ 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










Your Answer






StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













 

draft saved


draft discarded


















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






























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.






share|improve this answer




















  • 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'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














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.






share|improve this answer




















  • 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'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












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.






share|improve this answer












<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.







share|improve this answer












share|improve this answer



share|improve this answer










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'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
















  • 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'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















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












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.






share|improve this answer
















  • 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










  • @unwind, the prefix si_ 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














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.






share|improve this answer
















  • 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










  • @unwind, the prefix si_ 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












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.






share|improve this answer













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.







share|improve this answer












share|improve this answer



share|improve this answer










answered 53 mins ago









Baum mit Augen

39.8k12112145




39.8k12112145







  • 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










  • @unwind, the prefix si_ 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




    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






  • 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

















 

draft saved


draft discarded















































 


draft saved


draft discarded














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













































































Comments

Popular posts from this blog

What does second last employer means? [closed]

Installing NextGIS Connect into QGIS 3?

One-line joke