guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Passing C pointers through guile


From: Greg Troxel
Subject: Re: Passing C pointers through guile
Date: Wed, 23 Jul 2008 07:19:25 -0400
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.1 (berkeley-unix)

Ken Raeburn <address@hidden> writes:

> On Jul 9, 2008, at 12:55, Kjetil S. Matheussen wrote:
>> On Wed, 9 Jul 2008, Greg Troxel wrote:
>>> Does C guarantee that pointers fit in unsigned long?
>> I don't know. But in practice: Yes.
>
> According to various sources, 64-bit Windows uses an LLP64 model -- 
> meaning long is 32 bits, long long and pointers are 64 bits.  So, no.

I believe this is correct.  I have been the 64-bit portability weenie on
a large project at work, and been railing against int/* assignment.  The
overwhelming consensus among those of us that have actually dealt with
making programs run on non-ILP32 machines is that int/* assignments are
just plain wrong.

> Near as I can tell, C99 does not require that there be *any* integral
> type large enough to hold a pointer value (6.3.2.3 paragraph 6); and
> specifically, uintptr_t and intptr_t are optional types.  However, I
> expect any C99 implementation we're likely to run across will have
> such a type, and will define [u]intptr_t.  I don't have a copy of the
> C89 spec handy, though, and unfortunately that's where most compilers
> are these days.

My recent experience is that decent compilers are now essentially C99,
and that Microsoft compilers are mostly C99 with a a few defects.  Our
strategy has been to patch around the defective compilers by defining
the things we need somewhat like:

#if defined(LOSING_COMPILER_A)
#ifdef i386
typedef unsigned lont uintptr_t;
#else
#error DEFINE uintptr_t for yoru platfrom
#endif
#endif

and then just rely on the C99 definition.  Surprising little fixup has
been needed.

> In practice, it's also probably safe to use unsigned long long (or
> whatever Windows calls it) on the platforms that have it, and unsigned
> long on those that don't.  But testing compiler properties in autoconf
> and then using them in your installed headers may tie you to a
> particular compiler when more than one may be available (e.g.,
> vendor's compiler and gcc).

If we have to store a pointer we should just use void *.  I see Ken's
point about testing, but that quickly leads to madness as he notes.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]