I have the following in a header file:

h file (lines numbers from vi, not in the file.)

56
57 typedef struct shm_information {
58 struct shm_information *next; /* pointer to the next information */
59 struct shm_information *prev; /* pointer to the previous information */
60 char used; /* this is for bootstrapping a new image */
61 char *start; /* start of a free spot */
62 int length; /* length of the free spot */
63
64 } SHM_INFORMATION, *SHM_INFOPTR;
65
66
67
68 #define SHM_INFO_SIZE (sizeof (struct shm_information))

As far as I can see this is almost identical to the example in

K&R Whitebook (page 140).

gcc compiler on etch [gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) ] throws the following error messages:


gcc -c -I/home/spirals/Desktop/work/dpms/sys/include -I -L/home/spirals/Desktop/work/dpms/work/testscrobj -L/usr/lib /home/spirals/Desktop/work/dpms/work/testscrobj/shm_attach.c
In file included from /home/spirals/Desktop/work/dpms/work/testscrobj/shm_attach.c:23:
/home/spirals/Desktop/work/dpms/sys/include/dpms_shm.h:57: error: redefinition of ‘struct shm_information’
/home/spirals/Desktop/work/dpms/sys/include/dpms_shm.h:64: error: redefinition of typedef ‘SHM_INFORMATION’
/home/spirals/Desktop/work/dpms/sys/include/dpms_shm.h:64: error: previous declaration of ‘SHM_INFORMATION’ was here
/home/spirals/Desktop/work/dpms/sys/include/dpms_shm.h:64: error: redefinition of typedef ‘SHM_INFOPTR’
/home/spirals/Desktop/work/dpms/sys/include/dpms_shm.h:64: error: previous declaration of ‘SHM_INFOPTR’ was here
make: [shm_attach] Error 1 (ignored)
testrig done


Any suggestions. This code compiled clean on SCO? (around 1990) and later on Solaris 8 (in each case with the native compiler) , so I am at a loss why gcc is acting up!

I also did a grep for shm_information and SHM_INFORMATION nothing found.

Sounds like your header file is getting included twice. Do you have header guards in place (those things at the very top of the header like #ifndef MYHEADERNAME_H #define MYHEADERNAME_H and a corresponding #endif at the very bottom)?

Judy

Thank you for your reply, there are no header guards in these files. When I wrote it back in 1990 (yes that long ago) it worked fine. It is real K&R code. Unfortunately gcc is not ( correct me if i am wrong) a K&R complaint compiler, so it breaks my stuff. In trying to get it running I but this bug in, addled brain. I am adding the guards having been caught out and then I am now onto next problem [lot of shared memory manipulation]. very many thanks.:):):):study:

I'm not sure you can declare K&R to be a standard that a compiler must meet. The issue is how the compiler handles a second declaration that identically matches a previous declaration and I don't have the C spec handy to check what it says about that issue to know whether gcc is compliant or not. Did K&R even address how a compiler should handle that case?

Judy