jensen@gt-eedsp.UUCP (P. Allen Jensen) (08/15/88)
I am in the process of porting the X11R2 libraries and some client
routines to a Multiflow TRACE system. The system is a VLIW machine
running BSD4.3. When I try to build the libraries, I get lots of
"invalid initializer" errors from Xt and Xaw due to the following
macro defined in Intrinsic.h:
#define XtOffset(type,field) ((unsigned int)&(((type)NULL)->field))
The Multiflow compiler does not like this construct as a static or
global initializer. Has anyone else had this problem and if so,
how did you correct it (ie can you send me a patch) ?
If no one responds with a patch in a few days, I will attempt to
correct the problem myself and submit a patch for review.
Thanks,
--
P. Allen Jensen
Georgia Tech, School of Electrical Engineering, Atlanta, GA 30332-0250
USENET: ...!{allegra,hplabs,ihnp4,ulysses}!gatech!gt-eedsp!jensen
INTERNET: jensen@gteedsp.gatech.edujim@EXPO.LCS.MIT.EDU (Jim Fulton) (08/16/88)
The R2 XtOffset macro causes compilers that are fairly picky about pointer arithmetic to complain. The following version will be used in R3: #define XtOffset(type,field) \ ((unsigned int) (((caddr_t) (&(((type)NULL)->field))) - \ ((caddr_t) NULL))) Jim Fulton MIT X Consortium
jensen@gt-eedsp.UUCP (P. Allen Jensen) (08/16/88)
In article <8808152028.AA18193@EXPO.LCS.MIT.EDU>, jim@EXPO.LCS.MIT.EDU (Jim Fulton) writes: > > The R2 XtOffset macro causes compilers that are fairly picky about pointer > arithmetic to complain. The following version will be used in R3: > > #define XtOffset(type,field) \ > ((unsigned int) (((caddr_t) (&(((type)NULL)->field))) - \ > ((caddr_t) NULL))) Unfortunately, the new macro does not correct the problem. Is the Multiflow compiler to picky ? -- P. Allen Jensen Georgia Tech, School of Electrical Engineering, Atlanta, GA 30332-0250 USENET: ...!{allegra,hplabs,ihnp4,ulysses}!gatech!gt-eedsp!jensen INTERNET: jensen@gteedsp.gatech.edu
paul@torch.UUCP (Paul Andrews) (08/31/88)
In article <392@gt-eedsp.UUCP> jensen@gt-eedsp.UUCP (P. Allen Jensen) writes: >In article <8808152028.AA18193@EXPO.LCS.MIT.EDU>, jim@EXPO.LCS.MIT.EDU (Jim Fulton) writes: >> >> The R2 XtOffset macro causes compilers that are fairly picky about pointer >> arithmetic to complain. The following version will be used in R3: >> >> #define XtOffset(type,field) \ >> ((unsigned int) (((caddr_t) (&(((type)NULL)->field))) - \ >> ((caddr_t) NULL))) > > >Unfortunately, the new macro does not correct the problem. Is the >Multiflow compiler to picky ? I'm sorry if someone has already responded to this but we have had the same problem. We are running Unisoft V.2.2 with the portable C compiler. It finds the complexity of the define to much for it. In the end we reduced it to the following and put up with the warnings (there are lots of them). We have submitted a bug report about this to Unisoft: #ifdef UNISOFTV #define XtOffset(type,field) (&(((type)NULL)->field)) #else Hope this is of use - Paul.
hagens@CS.WISC.EDU (09/02/88)
> In article <392@gt-eedsp.UUCP> jensen@gt-eedsp.UUCP (P. Allen Jensen) writes: > >In article <8808152028.AA18193@EXPO.LCS.MIT.EDU>, jim@EXPO.LCS.MIT.EDU (Jim Fulton) writes: > >> > >> The R2 XtOffset macro causes compilers that are fairly picky about pointer > >> arithmetic to complain. The following version will be used in R3: > >> > >> #define XtOffset(type,field) \ > >> ((unsigned int) (((caddr_t) (&(((type)NULL)->field))) - \ > >> ((caddr_t) NULL))) This does not work for an IBM PC RT with the hc compiler. Does anyone know of a fix to the compiler or a work around? (Yes, I know about the _offsetof macro -- the problem is that it does not handle a field within a field: _offsetof(struct foo, a.b) will not be accepted. rob hagens uw madison computer science