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

Jonathan Pryor jonpryor at vt.edu
Fri May 23 08:37:01 EDT 2003


On Fri, 2003-05-23 at 03:18, Piers Haken wrote:
<snip/>
> For win32/64, sizeof(ptrdiff_t) == sizeof(size_t)
> However, on win64, sizeof(size_t) != sizeof(long)
> 
> MSVC has no 'long long', but you can conditionally typedef unsigned
> _int64. In fact, I would suggest doing this in a common header to
> prevent refactoring in the future.
> 
> Piers.

This is why I was trying to avoid 'long', as I know that Win64/long is a
32-bit quantity.  (Win64 is a P64 environment, not LP64 like most "sane"
platforms.)  As for why LP64 is "sane" see:

	http://www.opengroup.org/public/tech/aspen/lp64_wp.htm

If keeping with C89 data types, ptrdiff_t or size_t are probably the
best types to hold a pointer in.

Personally, I'd still rather use the C99 uintptr_t and provide a
compatibility header for older platforms, as uintptr_t makes it explicit
that a pointer will be held.  I've actually written such a header once,
and would be more than happy to share if there's any request for it.

 - Jon

> > -----Original Message-----
> > From: Jonathan Pryor [mailto:jonpryor at vt.edu] 
> > Sent: Thursday, May 22, 2003 8:21 PM
> > To: Piers Haken
> > Cc: Bernie Solomon; Dick Porter; Mono Development List
> > Subject: RE: [Mono-devel-list] Non GCC compiler patch - 
> > ip_mreq &HP'sheaders
> > 
> > 
> > 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
> > 
> > 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list




More information about the Mono-devel-list mailing list