[Mono-devel-list] Non GCC compiler patch - ip_mreq &HP'sheaders

[Piers Haken]

How about ptrdiff_t?

> -----Original Message-----
> From: Jonathan Pryor [mailto:jonpryor at vt.edu] 
> Sent: Thursday, May 22, 2003 9:52 AM
> To: Bernie Solomon
> Cc: Dick Porter; Mono Development List
> Subject: Re: [Mono-devel-list] Non GCC compiler patch - 
> ip_mreq &HP'sheaders
> 
> 
> The C99 type to use for an an int big enough to hold a 
> pointer is intptr_t and uintptr_t (signed vs. unsigned 
> versions) in <stdint.h>
> 
> However, I'm not sure we can assume C99 support (MSVC doesn't 
> have <stdint.h> last time I checked).
> 
> The next best bet is probably size_t.  Long isn't safe, as it 
> would only be large enough to hold a pointer in an LP64 
> model, but Windows will be using a P64 model, so "long" won't 
> be portable to Windows (unless using GCC, which would have 
> intptr_t...).
> 
> 'long long' isn't supported by MSVC (and likely other 
> compilers), so that's not an option either.  Plus, it's 
> always 64-bits, so it would be needlessly large on 32-bit platforms.
> 
> Personally, I'd use intptr_t and provide a "fake" <stdint.h> 
> for platforms that don't already have it (Windows).  The 
> default intptr_t could default to an alias for size_t.  This 
> should be safe and fairly future-proof.
> 
>  - Jon
> 
> On Thu, 2003-05-22 at 12:17, Bernie Solomon wrote:
> > io-layer/daemon-messages.c needs _XOPEN_SOURCE_EXTENDED for 
> cmsghdr so 
> > it seems impossible to have this compile and socket-io.c at 
> the same 
> > time - but this is the only file that needs it. So an alternative 
> > which feels slightly less yucky is to have _XOPEN_SOURCE defined 
> > everywhere by configure
> > 
> > #ifdef __hpux // is this the right symbol? or should it be 
> something 
> > defined by configure. #define _XOPEN_SOURCE_EXTENDED
> > #endif
> > 
> > at the top of daemon-messages.c to get cmsghdr.
> > 
> > BTW - I have seen no answers to my question on the type to 
> use for an 
> > int big enough to hold a pointer - is there an official 
> story on that?
> > 
> > Bernie Solomon
> > ----- Original Message -----
> > From: "Dick Porter" <dick at ximian.com>
> > To: "Bernie Solomon" <bernard at ugsolutions.com>
> > Cc: <mono-devel-list at lists.ximian.com>
> > Sent: Thursday, May 22, 2003 8:39 AM
> > Subject: Re: [Mono-devel-list] Non GCC compiler patch - ip_mreq &
> > HP'sheaders
> > 
> > 
> > > On Wed, 2003-05-21 at 22:46, Bernie Solomon wrote:
> > > > I looked at this a little more. So far the best I have come up 
> > > > with is
> > have
> > > > _XOPEN_SOURCE_EXTENDED defined for all compiles as it 
> is needed in 
> > > > other files and in socket-io.c have something like:
> > > >
> > > > #ifdef __hpux // or some equivalent
> > > > #undef _XOPEN_SOURCE_EXTENDED
> > > > #define _XOPEN_SOURCE
> > > > #endif
> > > >
> > > > before the appropriate includes so that ip_mreq comes 
> out (it is 
> > > > under
> > an
> > > > ifndef _XOPEN_SOURCE_EXTENDED in 
> /usr/include/netinet/in.h). Ugly 
> > > > but at least the code is compiled in this way.
> > >
> > > Yuck.
> > >
> > > Do you know offhand which other places require the 
> _EXTENDED define?  
> > > Is it possible to have configure.in give a set of 
> preprocessor flags 
> > > that do the right thing for hpux everywhere?  If not then 
> we'll just 
> > > have to live with that workaround in socket-io.c.
> > >
> > > Apart from this struct ip_mreq business, the changes to io-layer, 
> > > monitor.c and process.c look fine to me.  The other changes will 
> > > have to be reviewed by the owners of those bits of code.
> > >
> > > - Dick
> > >
> > >
> > 
> > _______________________________________________
> > Mono-devel-list mailing list
> > Mono-devel-list at lists.ximian.com 
> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com 
> http://lists.ximian.com/mailman/listinfo/mono-> devel-list
>