Why does prevent 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
10
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 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







share|improve this question



















  • 4




    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.
    2 hours ago






  • 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
    2 hours ago






  • 2




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







  • 3




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














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







share|improve this question



















  • 4




    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.
    2 hours ago






  • 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
    2 hours ago






  • 2




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







  • 3




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












up vote
10
down vote

favorite
1









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







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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 29 mins ago









Boann

36.2k1286118




36.2k1286118










asked 2 hours ago









SRG

11210




11210







  • 4




    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.
    2 hours ago






  • 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
    2 hours ago






  • 2




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







  • 3




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












  • 4




    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.
    2 hours ago






  • 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
    2 hours ago






  • 2




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







  • 3




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







4




4




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.
2 hours 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.
2 hours ago




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
2 hours 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
2 hours ago




2




2




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




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





3




3




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




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












2 Answers
2






active

oldest

votes

















up vote
11
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
    1 hour ago






  • 2




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







  • 1




    But isn't signal.h a standard header?
    – Kevin
    1 hour 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
    1 hour 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
    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
    2 hours ago










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






  • 1




    @unwind 2.2.2 The namespace
    – user463035818
    2 hours ago






  • 1




    how can a prefix be reserved?
    – Jean-François Fabre
    2 hours ago






  • 3




    @Jean-FrançoisFabre Probably in the same manner they've reserved a _t suffix
    – VTT
    2 hours 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-does-signal-h-prevent-the-use-of-si-as-prefix-for-the-name-of-some-vari%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
11
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
    1 hour ago






  • 2




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







  • 1




    But isn't signal.h a standard header?
    – Kevin
    1 hour 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
    1 hour 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
    1 hour ago














up vote
11
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
    1 hour ago






  • 2




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







  • 1




    But isn't signal.h a standard header?
    – Kevin
    1 hour 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
    1 hour 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
    1 hour ago












up vote
11
down vote



accepted







up vote
11
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 1 hour ago









Jonathan Leffler

552k866561009




552k866561009










answered 2 hours ago









Barmar

410k34235337




410k34235337







  • 1




    Aren't identifiers starting with '__' reserved for the implementation? Can't it use that instead? Or is that something else?
    – Kevin
    1 hour ago






  • 2




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







  • 1




    But isn't signal.h a standard header?
    – Kevin
    1 hour 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
    1 hour 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
    1 hour ago












  • 1




    Aren't identifiers starting with '__' reserved for the implementation? Can't it use that instead? Or is that something else?
    – Kevin
    1 hour ago






  • 2




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







  • 1




    But isn't signal.h a standard header?
    – Kevin
    1 hour 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
    1 hour 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
    1 hour ago







1




1




Aren't identifiers starting with '__' reserved for the implementation? Can't it use that instead? Or is that something else?
– Kevin
1 hour ago




Aren't identifiers starting with '__' reserved for the implementation? Can't it use that instead? Or is that something else?
– Kevin
1 hour ago




2




2




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





1




1




But isn't signal.h a standard header?
– Kevin
1 hour ago




But isn't signal.h a standard header?
– Kevin
1 hour 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
1 hour 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
1 hour 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
1 hour 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
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
    2 hours ago










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






  • 1




    @unwind 2.2.2 The namespace
    – user463035818
    2 hours ago






  • 1




    how can a prefix be reserved?
    – Jean-François Fabre
    2 hours ago






  • 3




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










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






  • 1




    @unwind 2.2.2 The namespace
    – user463035818
    2 hours ago






  • 1




    how can a prefix be reserved?
    – Jean-François Fabre
    2 hours ago






  • 3




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










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






  • 1




    @unwind 2.2.2 The namespace
    – user463035818
    2 hours ago






  • 1




    how can a prefix be reserved?
    – Jean-François Fabre
    2 hours ago






  • 3




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










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






  • 1




    @unwind 2.2.2 The namespace
    – user463035818
    2 hours ago






  • 1




    how can a prefix be reserved?
    – Jean-François Fabre
    2 hours ago






  • 3




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












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




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




1




1




@unwind 2.2.2 The namespace
– user463035818
2 hours ago




@unwind 2.2.2 The namespace
– user463035818
2 hours ago




1




1




how can a prefix be reserved?
– Jean-François Fabre
2 hours ago




how can a prefix be reserved?
– Jean-François Fabre
2 hours ago




3




3




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




@Jean-FrançoisFabre Probably in the same manner they've reserved a _t suffix
– VTT
2 hours 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-does-signal-h-prevent-the-use-of-si-as-prefix-for-the-name-of-some-vari%23new-answer', 'question_page');

);

Post as a guest
































































Comments

Post a Comment

Popular posts from this blog

Long meetings (6-7 hours a day): Being “babysat” by supervisor

Image
Clash Royale CLAN TAG #URR8PPP .everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0; up vote 31 down vote favorite 4 I hold a PhD in mechanical engineering with a 7 year background in self-guided, self-paced research including 2 years as a graduate level course instructor and a subject matter expert for various engineering projects in a university setting in the United States. For the last 10-11 months, I am working in a research industry in France where my task is to debug C++ spaghetti code written over a period of several years by my current supervisor. It is a team of 2: just I and my supervisor. Diurnally, I am posed with a "bug of the day" to get out of this C++ code. My supervisor generally gives me about 15-30 minutes to solve it and then accosts me about whether or not the task is completed and then rinses and repeats this until the end of the day. Off-late, my supervisor has been holding 6-7 hour long "meetin
Read more

Is the Concept of Multiple Fantasy Races Scientifically Flawed? [closed]

Image
Clash Royale CLAN TAG #URR8PPP up vote 2 down vote favorite Many fantasy worlds have multiple humanoid species (elves, orcs, humans, etc) living in the same world, in addition to that, they often have the ability to interbreed. And I can't help but question their believability... fantasy-races reproduction interspecies-relations share | improve this question edited Aug 9 at 14:46 Michael Kjörling ♦ 21.1k 10 85 161 asked Aug 9 at 13:13 Chlodio 118 6 closed as unclear what you're asking by MichaelK, Gryphon, John, Vincent, Frostfyre Aug 9 at 15:25 Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question. 3 Stack Exchange exist to
Read more

Confectionery

Image
Prepared foods made with a lot of sugar or other cabohydrates "Sweetmeat" redirects here. For the racehorse, see Sweetmeat (horse). Not to be confused with Sweetbread. This Kransekake is a traditional Scandinavian baker's confection. Confectionery is the art of making confections , which are food items that are rich in sugar and carbohydrates. Exact definitions are difficult. [1] In general, though, confectionery is divided into two broad and somewhat overlapping categories, bakers' confections and sugar confections. [2] Bakers' confectionery, also called flour confections , includes principally sweet pastries, cakes, and similar baked goods. Sugar confectionery includes candies ( sweets in British English), candied nuts, chocolates, chewing gum, bubble gum, pastillage, and other confections that are made primarily of sugar. In some cases, chocolate confections (confections made of chocolate) are treated as a separate category, as are sugar-free versions of
Read more