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

[Jonathan Pryor]

ptrdiff_t would probably work; I had forgotten about that type.  The one
potential problem is that it's a signed integer type, which could lead
to sign extension problems when performing widening operations, and sign
extension would "destroy" the address held by the variable.

If you're careful and avoid implicit conversions, ptrdiff_t is probably
a safe answer.

Related question: does anybody know of any systems where
sizeof(ptrdiff_t) != sizeof(size_t)?

Thanks,
 - Jon

On Thu, 2003-05-22 at 19:09, Piers Haken wrote:
> 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
> > 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list