sigaction() and ANSI C

I'm tearing my hair out with a problem at the moment. I've managed to reduce it to a very simple example below:

Code:

---

#include <signal.h>

struct sigaction action;

---

if you try compiling this as with:

Code:

---

gcc -ansi test.c -c

---

it prints:

Code:

---

test.c:3: error: storage size of `action' isn't known

---

if I try with

Code:

---

gcc test.c -c

---

it all compiles fine.

The problem is I really need to use sigaction, and from the man pages it looks like the only way to use it is for me to declare the struct somewhere, and I also really need to use -ansi to force it to use the ANSI C 89 standard (part of the requirements). I thought that using -ansi wouldn't get in the way of using sigaction because sigaction is a POSIX system call. I'm also puzzled as to how if it doesn't know how big it is it could possibly compile in the first place. Is it possible to use sigaction with gcc -ansi, and if yes how?

Thanks,
Alan

Try adding:

Code:

---

#include <bits/sigaction.h>

---

> I also really need to use -ansi to force it to use the ANSI C 89 standard (part of the requirements).
http://www.eskimo.com/~scs/C-faq/q19.41.html

> because sigaction is a POSIX system call.
Maybe so, but it isn't part of ANSI-C

Generally, you need to isolate system dependencies in as few places as possible, so that most of your code can be compiled with -ansi

I had always assumed that ANSI C was just the grammar for the C language itself + the standard library, and that if I called a function that happened to be not part of the ANSI standard C library then that was all ok so long as I had included the appropriate definitions and linked against the right libraries correctly. Am I right in thinking then that -ansi sets something that makes the preprocessor ignore the non ANSI standard parts of signal.h? I have managed to solve the problem using just signal(), but using sigaction() seemed like a nicer solution given that when I recived a SIGCHLD it would tell me which pid it was associated with, as well as telling it to ignore stopped and continued. Sticking with just the ANSI standard is definatly the best approach with this project because it is required to run on several different flavours of UNIX.

Thanks for the answer,
Alan

> Am I right in thinking then that -ansi sets something that makes the preprocessor ignore the non ANSI standard parts of signal.h?
Yes.
Things which are not in ANSI-C get excluded when you specify -ansi, simply because they're not guaranteed to be everywhere else. Regard -ansi as a strict portability checker.

> because it is required to run on several different flavours of UNIX.
Perhaps you should relax the test a little bit, down to POSIX compatibility. That should allow you to port your code easily to most unices (plural of unix), and still use sigaction() since it is part of POSIX.

If you can't manage ANSI, at least POSIX is a good 2nd choice to go for.

If you have many source files, you should be able to arrange for nearly all of them to be compiled with -ansi, and just a few which rely on POSIX. That way, any porting surprises you do have will be localised in just a few places.