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;
...
<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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With