unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Greg Troxel <gdt@ir.bbn.com>
To: Ken Raeburn <raeburn@raeburn.org>
Cc: guile-user@gnu.org, "Kjetil S. Matheussen" <k.s.matheussen@notam02.no>
Subject: Re: Passing C pointers through guile
Date: Wed, 23 Jul 2008 07:19:25 -0400	[thread overview]
Message-ID: <rmiod4oj1aa.fsf@fnord.ir.bbn.com> (raw)
In-Reply-To: <85E93FB6-A50A-4A6A-8DAB-7ACEE47B3928@raeburn.org> (Ken Raeburn's message of "Thu, 10 Jul 2008 11:11:14 -0400")

Ken Raeburn <raeburn@raeburn.org> 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	other threads:[~2008-07-23 11:19 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cmu-lmtpd-16223-1215360367-2@mail-imap1.uio.no>
2008-07-06 16:13 ` Passing C pointers through guile Kjetil S. Matheussen
2008-07-06 19:20   ` Ludovic Courtès
2008-07-09 16:48   ` Greg Troxel
2008-07-09 16:55     ` Kjetil S. Matheussen
2008-07-09 19:54       ` Ludovic Courtès
2008-07-10 15:11       ` Ken Raeburn
2008-07-23 11:19         ` Greg Troxel [this message]
2008-07-10 12:54 Kjetil S. Matheussen
  -- strict thread matches above, loose matches on Subject: below --
2008-07-04 22:18 Maciek Godek
2008-07-05 16:59 ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=rmiod4oj1aa.fsf@fnord.ir.bbn.com \
    --to=gdt@ir.bbn.com \
    --cc=guile-user@gnu.org \
    --cc=k.s.matheussen@notam02.no \
    --cc=raeburn@raeburn.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).