[ragel-users] Debugging colm for win32.

[William Ahern]

On Tue, Apr 01, 2014 at 04:20:11PM -0400, Bob Paddock wrote:
> > This isn't true in C. In C the only well-defined way to convert a pointer to
> > an integer and back again is via intptr_t or uintptr_t.
> >
> > Does C++ really require the same behavior for size_t?
> 
> cstdint.hpp from Boost, which is what I have at hand says:
> 
> // intptr_t/uintptr_t are defined separately because they are optional
> and not universally available
> 

intptr_t and uintptr_t are optional because the ability to do a round-trip
conversion from a pointer through an integer is not something all
environments support or that the standard requires. The C standard only
provides intptr_t as a common type _if_ the environment supports the
operation.

If <stdint.h> is available, then I'd be surprised if intptr_t wasn't
defined, presuming the operation was supported. <stdint.h> was created by
C99, the same standard that defined intptr_t.

size_t is only required to be wide enough to describe the size of any
_single_ valid object in the system, which basically means wide enough for
the sizeof operator to work. Pointers can be wider than size_t. The most
common example was x86 real mode, but everybody discounts that as no longer
applicable.

If you Google around, you'll find that, for example, the C environment for
the AS/400 (and successors) has 128-bit data and function pointers but
size_t is only 32-bit and doubles 64-bit. Therefore, presuming the AS/400
supported integer/pointer conversions (it might not, because that might
allow circumventing memory capability protections), you would have to use
intptr_t or uintptr_t.


_______________________________________________
ragel-users mailing list
ragel-users at complang.org
http://www.complang.org/mailman/listinfo/ragel-users