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

Piers Haken piersh at friskit.com
Fri May 23 03:18:54 EDT 2003 

The only time I can think of that an implicit conversion to a ptrdiff_t
would be a problem is with a shortening cast and such a cast on a
pointer type would generally be an error anyway.

The best way to prevent this is to throw -Werror and turn on
pedantic/strict warnings and only disable (#pragma) them when absolutely
necessary. I'm a big fan of -Wall -Werror (or /WX /W4) as along-term
solution to these kinds of problems. Of course, throwing them in the
middle of a project is kind of a pain, but really that's the whole
point.

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.

> -----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
> 
>

More information about the Mono-devel-list mailing list