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.
    1 hour 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
    1 hour ago






  • 2




    @alterigel sorry, si_vy1ghad563nvy43wd is also a reserved keyword.
    – Jean-François Fabre
    1 hour 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
    1 hour ago







  • 2




    @AndrewHenle okay this was a joke.
    – Jean-François Fabre
    1 hour 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.
    1 hour 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
    1 hour ago






  • 2




    @alterigel sorry, si_vy1ghad563nvy43wd is also a reserved keyword.
    – Jean-François Fabre
    1 hour 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
    1 hour ago







  • 2




    @AndrewHenle okay this was a joke.
    – Jean-François Fabre
    1 hour 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 52 mins ago

























asked 1 hour 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.
    1 hour 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
    1 hour ago






  • 2




    @alterigel sorry, si_vy1ghad563nvy43wd is also a reserved keyword.
    – Jean-François Fabre
    1 hour 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
    1 hour ago







  • 2




    @AndrewHenle okay this was a joke.
    – Jean-François Fabre
    1 hour 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.
    1 hour 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
    1 hour ago






  • 2




    @alterigel sorry, si_vy1ghad563nvy43wd is also a reserved keyword.
    – Jean-François Fabre
    1 hour 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
    1 hour ago







  • 2




    @AndrewHenle okay this was a joke.
    – Jean-François Fabre
    1 hour 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.
1 hour 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.
1 hour 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
1 hour 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
1 hour ago




2




2




@alterigel sorry, si_vy1ghad563nvy43wd is also a reserved keyword.
– Jean-François Fabre
1 hour ago




@alterigel sorry, si_vy1ghad563nvy43wd is also a reserved keyword.
– Jean-François Fabre
1 hour 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
1 hour 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
1 hour ago





2




2




@AndrewHenle okay this was a joke.
– Jean-François Fabre
1 hour ago




@AndrewHenle okay this was a joke.
– Jean-François Fabre
1 hour ago












2 Answers
2






active

oldest

votes

















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






share|improve this answer


















  • 1




    Aren't identifiers starting with '__' reserved for the implementation? Can't it use that instead? Or is that something else?
    – Kevin
    54 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
    49 mins ago







  • 1




    But isn't signal.h a standard header?
    – Kevin
    47 mins ago






  • 1




    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
    43 mins ago






  • 1




    @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
    40 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
    1 hour ago










  • @unwind, the prefix si_ is reserved when using <signal.h>
    – R Sahu
    1 hour ago






  • 1




    @unwind 2.2.2 The namespace
    – user463035818
    1 hour ago






  • 1




    how can a prefix be reserved?
    – Jean-François Fabre
    1 hour ago






  • 2




    @Jean-FrançoisFabre Probably in the same manner they've reserved a _t suffix
    – VTT
    1 hour 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
7
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.






share|improve this answer


















  • 1




    Aren't identifiers starting with '__' reserved for the implementation? Can't it use that instead? Or is that something else?
    – Kevin
    54 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
    49 mins ago







  • 1




    But isn't signal.h a standard header?
    – Kevin
    47 mins ago






  • 1




    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
    43 mins ago






  • 1




    @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
    40 mins ago














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






share|improve this answer


















  • 1




    Aren't identifiers starting with '__' reserved for the implementation? Can't it use that instead? Or is that something else?
    – Kevin
    54 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
    49 mins ago







  • 1




    But isn't signal.h a standard header?
    – Kevin
    47 mins ago






  • 1




    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
    43 mins ago






  • 1




    @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
    40 mins ago












up vote
7
down vote



accepted







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






share|improve this answer














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







share|improve this answer














share|improve this answer



share|improve this answer








edited 38 mins ago









Jonathan Leffler

552k866561009




552k866561009










answered 1 hour ago









Barmar

410k34235336




410k34235336







  • 1




    Aren't identifiers starting with '__' reserved for the implementation? Can't it use that instead? Or is that something else?
    – Kevin
    54 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
    49 mins ago







  • 1




    But isn't signal.h a standard header?
    – Kevin
    47 mins ago






  • 1




    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
    43 mins ago






  • 1




    @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
    40 mins ago












  • 1




    Aren't identifiers starting with '__' reserved for the implementation? Can't it use that instead? Or is that something else?
    – Kevin
    54 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
    49 mins ago







  • 1




    But isn't signal.h a standard header?
    – Kevin
    47 mins ago






  • 1




    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
    43 mins ago






  • 1




    @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
    40 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
54 mins ago




Aren't identifiers starting with '__' reserved for the implementation? Can't it use that instead? Or is that something else?
– Kevin
54 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
49 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
49 mins ago





1




1




But isn't signal.h a standard header?
– Kevin
47 mins ago




But isn't signal.h a standard header?
– Kevin
47 mins ago




1




1




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
43 mins ago




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
43 mins ago




1




1




@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
40 mins ago




@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
40 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
    1 hour ago










  • @unwind, the prefix si_ is reserved when using <signal.h>
    – R Sahu
    1 hour ago






  • 1




    @unwind 2.2.2 The namespace
    – user463035818
    1 hour ago






  • 1




    how can a prefix be reserved?
    – Jean-François Fabre
    1 hour ago






  • 2




    @Jean-FrançoisFabre Probably in the same manner they've reserved a _t suffix
    – VTT
    1 hour 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
    1 hour ago










  • @unwind, the prefix si_ is reserved when using <signal.h>
    – R Sahu
    1 hour ago






  • 1




    @unwind 2.2.2 The namespace
    – user463035818
    1 hour ago






  • 1




    how can a prefix be reserved?
    – Jean-François Fabre
    1 hour ago






  • 2




    @Jean-FrançoisFabre Probably in the same manner they've reserved a _t suffix
    – VTT
    1 hour 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 1 hour 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
    1 hour ago










  • @unwind, the prefix si_ is reserved when using <signal.h>
    – R Sahu
    1 hour ago






  • 1




    @unwind 2.2.2 The namespace
    – user463035818
    1 hour ago






  • 1




    how can a prefix be reserved?
    – Jean-François Fabre
    1 hour ago






  • 2




    @Jean-FrançoisFabre Probably in the same manner they've reserved a _t suffix
    – VTT
    1 hour 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
    1 hour ago










  • @unwind, the prefix si_ is reserved when using <signal.h>
    – R Sahu
    1 hour ago






  • 1




    @unwind 2.2.2 The namespace
    – user463035818
    1 hour ago






  • 1




    how can a prefix be reserved?
    – Jean-François Fabre
    1 hour ago






  • 2




    @Jean-FrançoisFabre Probably in the same manner they've reserved a _t suffix
    – VTT
    1 hour 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
1 hour 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
1 hour ago












@unwind, the prefix si_ is reserved when using <signal.h>
– R Sahu
1 hour ago




@unwind, the prefix si_ is reserved when using <signal.h>
– R Sahu
1 hour ago




1




1




@unwind 2.2.2 The namespace
– user463035818
1 hour ago




@unwind 2.2.2 The namespace
– user463035818
1 hour ago




1




1




how can a prefix be reserved?
– Jean-François Fabre
1 hour ago




how can a prefix be reserved?
– Jean-François Fabre
1 hour ago




2




2




@Jean-FrançoisFabre Probably in the same manner they've reserved a _t suffix
– VTT
1 hour ago




@Jean-FrançoisFabre Probably in the same manner they've reserved a _t suffix
– VTT
1 hour 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













































































Popular posts from this blog

How to check contact read email or not when send email to Individual?

Displaying single band from multi-band raster using QGIS

How many registers does an x86_64 CPU actually have?