Hi,
When I define any structure member variable with either si_signo, si_code, or si_errno, I got a compiler syntax error. The workaround is to undef these member variables. These variables are posix standard variable for siginfo_t struct. But since I define my own struct tag the compier is not suppose to complaint about it.
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#undef si_code
struct test_unknown_error
{
int si_signo_1;
int si_code;
int si_errno;
}test_variable;
main()
{
test_variable.si_signo = 5;
printf("si_signo : %d\n", test_variable.si_signo);
return 0;
}
define
please use the preview function when posting, code with <-s must be escaped to be readable.
where have you read that you can use indentifiers that have a system meaning? the si_-prefixes are there for a reason, to put the member variables into some kind of namespace. sometimes these are defines for compatibility reasons, because the variable is named differently on this system, e.g. because of competing standards. posix vs. bsd are competing standards, so the define may just map the posix name to the native bsd name. this has to be done to make code adhering to standards compile and is itself standard practice. sometimes you can control this behavior with feature test macros you have to define before including the corresponding header, to make the header know which standard your code adheres to.
why did you even name your member variables after the posix ones? member variables are accessed by offset, not by name (the names' offsets being equal only because the same header is included in all source files). if you don't use the same struct, you can choose the names freely. if you want your own struct as an extension of the system struct, you have to include the system struct into your own struct, because the structure layout is not fixed by posix and the members could be ordered or aligned differently on different systems.
the compiler is just doing its job. if the job description includes complaining, it has to complain here. you can't declare variables named TZ or PATH_MAX either, if you include the well known headers defining these values. if you have a function named read() in your code, the libc function gets overwritten by the linker and you can't read from files or streams any more, the same goes for every libc function (and some see that as a feature). this problem is solved by later languages that have namespaces, but if you are using C, you have to live the C culture.