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

[Jonathan Pryor]

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