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

Clash Royale CLAN TAG#URR8PPP

up vote
8
down vote

favorite

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

c++ c linux

share|improve this question

edited 7 mins ago

asked 57 mins ago

SRG

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
  

  
  
  
  

 | 
show 5 more comments

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

c++ c linux

share|improve this question

edited 7 mins ago

asked 57 mins ago

SRG

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
  

  
  
  
  

 | 
show 5 more comments

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

c++ c linux

share|improve this question

edited 7 mins ago

asked 57 mins ago

SRG

1029

I have been debugging a strange compilation error that I was getting inside my code, and I ended up finding out that I cannot use the prefix si_ for some variable names (of any type) if <signal.h> is included.

Here is a very simple source code example that reproduces the issue:

#include <signal.h>

int main(void)

 int si_value = 0;

 return 0;

If I try to compile this with the GNU C Compiler gcc, I get the following error:

> gcc example.c
In file included from /usr/include/signal.h:57:0,
 from example.c:2:
example.c: In function ‘main’:
example.c:6:9: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘.’ token
 int si_value = 0;
 ^
example.c:6:9: error: expected expression before ‘.’ token

Nonetheless, if I use another name such as si_value2, the error doesn't show up. As a reference, I'm using GCC v7.3.0 inside Ubuntu Mate 18.04.1 LTS. The same problem is observed with g++.

I suppose that this behaviour is due to some macro definition inside the <signal.h> header, but after going through it briefly, I couldn't seem to find anything really related.

I honestly can fix it by just using another name. However, my concern is: how could I elegantly avoid this type of issues in the future?

Thank you very much in advance and looking forward to learn from you all!

---

Update: As @F.X. has suggested, using gcc -E example.c shows up that the variable name is expanded (hence, the error):

...
 int 
# 6 "example.c" 3 4
 _sifields._rt.si_sigval 
# 6 "example.c"
 = 0;
...

c++ c linux

c++ c linux

share|improve this question

edited 7 mins ago

asked 57 mins ago

SRG

1029

share|improve this question

edited 7 mins ago

asked 57 mins ago

SRG

1029

share|improve this question

share|improve this question

edited 7 mins ago

edited 7 mins ago

edited 7 mins ago

asked 57 mins ago

SRG

1029

asked 57 mins ago

SRG

1029

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
  

  
  
  
  

 | 
show 5 more comments

• 
  
  
  

  
  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

 | 
show 5 more comments

2 Answers
2

active

oldest

votes

up vote
5
down vote



accepted

<signal.h> doesn't actually prevent using si_ as a prefix on your variables. However, the specification states that this prefix is reserved, in order to allow the header and the library functions that it declares to use these names, without having to worry that they'll conflict with your own variables.

So what's happening here is that si_value is defined in some way in the header file, perhaps as a macro or typedef, and your attempt to use the same name conflicts with this. If you used si_vy1ghad563nvy43wd it probably would work, but theoretically the header could use that name (thinking that it would be unlikely to conflict with anything an application programmer would use).

C doesn't have real namespaces, so naming conventions like this are used as a simple substitute.

share|improve this answer

answered 39 mins ago

Barmar

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
  

  
  
  
  

add a comment | 

up vote
7
down vote

how could I elegantly avoid this type of issues in the future?

You check some documentation for the headers you are using and avoid the names that are documented as reserved.

share|improve this answer

answered 53 mins ago

Baum mit Augen

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
  

  
  
  
  

 | 
show 4 more comments

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

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

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

Name Email

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

answered 39 mins ago

Barmar

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
  

  
  
  
  

add a comment | 

up vote
5
down vote



accepted

<signal.h> doesn't actually prevent using si_ as a prefix on your variables. However, the specification states that this prefix is reserved, in order to allow the header and the library functions that it declares to use these names, without having to worry that they'll conflict with your own variables.

So what's happening here is that si_value is defined in some way in the header file, perhaps as a macro or typedef, and your attempt to use the same name conflicts with this. If you used si_vy1ghad563nvy43wd it probably would work, but theoretically the header could use that name (thinking that it would be unlikely to conflict with anything an application programmer would use).

C doesn't have real namespaces, so naming conventions like this are used as a simple substitute.

share|improve this answer

answered 39 mins ago

Barmar

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
  

  
  
  
  

add a comment | 

up vote
5
down vote



accepted

up vote
5
down vote



accepted

<signal.h> doesn't actually prevent using si_ as a prefix on your variables. However, the specification states that this prefix is reserved, in order to allow the header and the library functions that it declares to use these names, without having to worry that they'll conflict with your own variables.

So what's happening here is that si_value is defined in some way in the header file, perhaps as a macro or typedef, and your attempt to use the same name conflicts with this. If you used si_vy1ghad563nvy43wd it probably would work, but theoretically the header could use that name (thinking that it would be unlikely to conflict with anything an application programmer would use).

C doesn't have real namespaces, so naming conventions like this are used as a simple substitute.

share|improve this answer

answered 39 mins ago

Barmar

410k34235336

<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

answered 39 mins ago

Barmar

410k34235336

share|improve this answer

share|improve this answer

answered 39 mins ago

Barmar

410k34235336

answered 39 mins ago

Barmar

410k34235336

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
  

  
  
  
  

add a comment | 

• 
  
  
  

  
  

  
  
  
  
  
  

  
  Thank you Barmar, this answer is exactly what I was looking for!
  – SRG
  32 mins ago
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

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

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  I think this is actually a POSIX thing, while __ is a C thing. So POSIX is trying to avoid names that are reserved to the C implementation.
  – Barmar
  4 mins ago
  
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

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

add a comment | 

up vote
7
down vote

how could I elegantly avoid this type of issues in the future?

You check some documentation for the headers you are using and avoid the names that are documented as reserved.

share|improve this answer

answered 53 mins ago

Baum mit Augen

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
  

  
  
  
  

 | 
show 4 more comments

up vote
7
down vote

how could I elegantly avoid this type of issues in the future?

You check some documentation for the headers you are using and avoid the names that are documented as reserved.

share|improve this answer

answered 53 mins ago

Baum mit Augen

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
  

  
  
  
  

 | 
show 4 more comments

up vote
7
down vote

up vote
7
down vote

how could I elegantly avoid this type of issues in the future?

You check some documentation for the headers you are using and avoid the names that are documented as reserved.

share|improve this answer

answered 53 mins ago

Baum mit Augen

39.8k12112145

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

answered 53 mins ago

Baum mit Augen

39.8k12112145

share|improve this answer

share|improve this answer

answered 53 mins ago

Baum mit Augen

39.8k12112145

answered 53 mins ago

Baum mit Augen

39.8k12112145

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
  

  
  
  
  

 | 
show 4 more comments

• 
  
  
  

  
  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

 | 
show 4 more comments

 

draft saved

draft discarded

 

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

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

Name Email

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

Name Email

Name

Email

Name Email

Name

Email