" Maynard) (11/19/89)
I'm trying to install C news, at the patchlevel 7/13 Nov 1989 level, on
my System V/AT 2.4 system. Trying to compile relay/hdrdefs.c, I get:
cc -I../include -I. -DVOID=int -DFLUSHEVERY=6 -O -c hdrdefs.c
"hdrdefs.c", line 49: compiler error: expression causes compiler loop:
try simplifying
I just tried it by hand, without the -O, and got the same error.
The relevant code is:
#ifndef offsetof
#define offsetof(type, mem) ((char *)&((type *)NULL)->mem - (char *)NULL)
#endif
static const char msgnm[] = "Message-ID:"; /* for rejection */
static const struct hdrdef msghdr = {
msgnm, STRLEN(msgnm), offsetof(struct headers, h_msgid) };
...with the last line being the one the compiler complains about.
Any ideas about how to simplify this one? Am I the only person to run
into this?
--
Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can
jay@splut.conmicro.com (eieio)| adequately be explained by stupidity.
{attctc,bellcore}!texbell!splut!jay +----------------------------------------
Shall we try for comp.protocols.tcp-ip.eniac next, Richard? - Brandon Allbery" Maynard) (11/19/89)
In article <3056@splut.conmicro.com> jay@splut.conmicro.com (Jay "you ignorant splut!" Maynard) writes: >#define offsetof(type, mem) ((char *)&((type *)NULL)->mem - (char *)NULL) Something just occurred to me, several hours after the original posting: Was this the problem whose fix I gave Henry a hard time about a few months ago about mixing pointers and integers? -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can jay@splut.conmicro.com (eieio)| adequately be explained by stupidity. {attctc,bellcore}!texbell!splut!jay +---------------------------------------- Shall we try for comp.protocols.tcp-ip.eniac next, Richard? - Brandon Allbery
mdm@cocktrice.UUCP (Mike Mitchell) (11/19/89)
In article <3056@splut.conmicro.com>, jay@splut.conmicro.com (Jay "you ignorant splut!" Maynard) writes: > > I'm trying to install C news, at the patchlevel 7/13 Nov 1989 level, on > my System V/AT 2.4 system. Trying to compile relay/hdrdefs.c, I get: > > The relevant code is: > #ifndef offsetof > #define offsetof(type, mem) ((char *)&((type *)NULL)->mem - (char *)NULL) > #endif > > Any ideas about how to simplify this one? Am I the only person to run > into this? > #ifndef offsetof #define offsetof(type, mem) (int)&(((type *)0)->(mem)) #endif Also be sure that you compile relaynews large model. It has the tendancy to blow up on really huge incoming batches in small model. Use the dbz routines in the contribution directory. Cnews operates fairly well on one of these Uport '286 things. -- Mike Mitchell BELL H (505) 471-7639 W (505) 473-4482 2020 Calle Lorca #43 ARPA mdm@cocktrice.UUCP Santa Fe, NM 87505 UUCP ...!uunet!dmk3b1!cocktrice!mdm
henry@utzoo.uucp (Henry Spencer) (11/21/89)
In article <3056@splut.conmicro.com> jay@splut.conmicro.com (Jay "you ignorant splut!" Maynard) writes: >"hdrdefs.c", line 49: compiler error: expression causes compiler loop: >try simplifying The offsetof() macro has a tendency to stress-test compilers. Try: #define offsetof(type, mem) ((int)&((type *)NULL)->mem) as an alternative. -- A bit of tolerance is worth a | Henry Spencer at U of Toronto Zoology megabyte of flaming. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (11/21/89)
In article <1989Nov20.181839.1546@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: | The offsetof() macro has a tendency to stress-test compilers. Try: | | #define offsetof(type, mem) ((int)&((type *)NULL)->mem) | | as an alternative. I would be very careful using this. Althoug I feel that the use of a zero cast to a non-void type is legal in sizeof, because of qualifying statements promising that it is not evaluated, I would not be surprized to see a compiler reject this one. I see how it works, I realize that it will work on many compilers, but I am suspicious that it is not really portable. I would put the definition in ifdefs at the very least, so that the required offsetof macro could be used on undamaged compilers. The error message reminds me of things I used to get out of MSC some years ago. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon
gsteckel@jeska.East.Sun.COM (Geoff Steckel - Sun BOS Software) (11/22/89)
In article <1676@crdos1.crd.ge.COM> davidsen@crdos1.UUCP (bill davidsen) writes: >In article <1989Nov20.181839.1546@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >| The offsetof() macro has a tendency to stress-test compilers. Try: >| #define offsetof(type, mem) ((int)&((type *)NULL)->mem) >| as an alternative. > > I would be very careful using this. Althoug I feel that the use of a >zero cast to a non-void type is legal in sizeof, because of qualifying >statements promising that it is not evaluated, I would not be surprized >to see a compiler reject this one. >bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) Last time I looked, ANSI-fied C compilers were required to accept that as the best way to determine offsets (inasmuch as an offset made sense on the implementation/hardware). The subtraction scheme was deprecated. This may have changed in the intervening months - and we all know how thoroughly compliant compilers can be... Every PCC-based and Green Hills compiler I've tried (ANSI and non-ANSI) has accepted it correctly. geoff steckel (gws%omnivor.uucp@wjh12.harvard.EDU) (...!husc6!wjh12!omnivor!gws) Disclaimer: I am not affiliated with Sun Microsystems, despite the From: line. This posting is entirely the author's responsibility.
henry@utzoo.uucp (Henry Spencer) (11/22/89)
>>| #define offsetof(type, mem) ((int)&((type *)NULL)->mem) >> >> I would be very careful using this. Althoug I feel that the use of a >>zero cast to a non-void type is legal in sizeof, because of qualifying >>statements promising that it is not evaluated, I would not be surprized >>to see a compiler reject this one. Most any way of computing the offset into a struct is inherently somewhat unportable. Both this and the original will work on most orthodox systems; neither is guaranteed. >Last time I looked, ANSI-fied C compilers were required to accept that >as the best way to determine offsets... Not so. ANSI C implementations are required to provide an offsetof() macro that works... somehow. No specific technique is promised to work; the implementation of that macro uses whatever black magic is appropriate, up to and including the possibility of invoking special compiler primitives. If we could have assumed an ANSI implementation, the whole issue would go away, because we wouldn't have to supply our own offsetof(). -- A bit of tolerance is worth a | Henry Spencer at U of Toronto Zoology megabyte of flaming. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
martin@mwtech.UUCP (Martin Weitzel) (11/23/89)
In article <1989Nov21.175136.3418@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: [lines deleted] >If we could have assumed an ANSI implementation, the whole issue would go >away, because we wouldn't have to supply our own offsetof(). Did you ever think about the following alternative to offsetof(): 1) Instead of offsetof() use #defined constants. 2) When 'make'ing the programm, *automatically* generate an #include-file with the required #defines by 2a) compile and run a programm, which calculates the offset by taking the difference of the struct.component-s adress and the struct-s adress, after casting both to char* IMHO this should be portable within all flavours of C-Compilers. BTW: I myself did not invent this approach, but I've forgotten where I read it (in some really good book about C-Programming - don't like to walk to my board of C books now :-) ).
henry@utzoo.uucp (Henry Spencer) (11/25/89)
In article <480@mwtech.UUCP> martin@mwtech.UUCP (Martin Weitzel) writes: >Did you ever think about the following alternative to offsetof(): >2) When 'make'ing the programm, *automatically* generate an > #include-file with the required #defines by > 2a) compile and run a programm, which calculates > the offset by taking the difference of the > struct.component-s adress and the struct-s adress... Can't say we'd thought about it, but it boils down to doing the same thing a step at a time in a separate program rather than all at once in the main program. I'm not sure that it really gains us much, except reducing the complexity of the expressions the compiler is asked to handle... and we made an explicit decision very early on that it was hopeless to try to cater to all the defective compilers in the world. If it gained us something on portability or something like that, that might be sufficient added motive to do it. As it is, it just looks like extra complexity for the sake of one or two broken compilers. Sorry. -- That's not a joke, that's | Henry Spencer at U of Toronto Zoology NASA. -Nick Szabo | uunet!attcan!utzoo!henry henry@zoo.toronto.edu