Path: utzoo!attcan!uunet!mcvax!ukc!stc!datlog!torch!paul
From: paul@torch.UUCP (Paul Andrews)
Newsgroups: comp.windows.x
Subject: Re: Problem compiling X11R2 on Multiflow under BSD4.3
Message-ID: <210@torch.UUCP>
Date: 31 Aug 88 12:56:52 GMT
References: <8808152028.AA18193@EXPO.LCS.MIT.EDU> <392@gt-eedsp.UUCP>
Reply-To: paul@torch.UUCP (Paul Andrews)
Organization: TORCH Computers Ltd., Cambridge, United Kingdom
Lines: 25

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.