[Mono-devel-list] Non GCC compiler patch - ip_mreq & HP'sheaders
jonpryor at vt.edu
Thu May 22 12:52:10 EDT 2003
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
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
> 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 &
> > 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
> > > _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
> > > 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
More information about the Mono-devel-list