From: Ken Raeburn <raeburn@raeburn.org>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: guile-devel@gnu.org
Subject: Re: more compilation failures: -DSCM_DEBUG_TYPING_STRICTNESS=2
Date: Wed, 2 Sep 2009 14:17:49 -0400 [thread overview]
Message-ID: <B36B297C-7383-4D25-9DD2-FD31E4C23AEB@raeburn.org> (raw)
In-Reply-To: <877hwheplm.fsf@gnu.org>
On Sep 2, 2009, at 04:08, Ludovic Courtès wrote:
>> In the Guile case, I'm a tiny bit concerned about some of the
>> pointer/
>> int games played (e.g., I'm pretty sure C99 does not guarantee that
>> you can convert an arbitrary uintptr_t value to pointer and back and
>> be guaranteed of getting the original value... but I don't know of a
>> platform that actually violates that assumption), but only a tiny
>> bit.
>
> Really? I think the whole purpose of `uintptr_t' is to allow that,
> isn't it?
It's the other way around that's guaranteed to work: void* ->
(u)intptr_t -> void*. So any value originally derived from a valid
pointer will work, but arbitrary values may not. Also, C99 talks
about uintptr_t as being capable of holding a converted pointer-to-
void; strictly speaking, I don't think it requires that a direct
conversion from/to any other pointer type (except possibly char*) work
the same way.
So, for example, uintptr_t may have 64 bits on a machine that uses 48-
bit pointers (segment+offset? also, some embedded processors have non-
power-of-two pointer or integer sizes, though I don't know whether
they have pointer and int types matching in size); pointers may have
trapping representations (invalid segment number?); storing an integer
value into a pointer register may cause certain bits to be masked off;
manipulation of pointer values in general registers may not preserve
bits known by the compiler not to be set in any valid or null
pointers; etc.
And then there's the whole NULL-vs-0 thing -- "0" is a null pointer
constant in source code, but strictly speaking the compiler produces a
null pointer constant there; it doesn't imply that the null pointer
has the same binary representation as 0, nor that a non-constant zero
value when cast to a pointer will be a null pointer, nor that memset(,
0,) gives you null pointers, nor that a null pointer cast to uintptr_t
will have the value 0, etc.
(For example, in an architecture with one pointer format for segment +
word offset, and a second representation for segment + word offset +
bit offset into word, a void* may require the second form, but a
struct pointer might use the former, if all structs are required to be
word-aligned. And converting a pointer to uintptr_t could just copy
bits around, giving consistent results only if you use the same
pointer form consistently in the conversions. And all-bits-zero may
store an invalid segment number that could lead to a trap when loaded
into a pointer register, and a "null pointer" may be represented with
a reserved non-zero segment number. This is not completely
theoretical... I once used a platform with multiple pointer types and
a null pointer representation using segment number -1, which could be
loaded without faulting but not dereferenced, but I'm rusty on some of
the details, and never got familiar with the C environment on it.)
Like I said, most platforms I know of, and all I know of that we're
likely to care about, will still meet these assumptions to the best of
my knowledge, so it's probably not a big problem. But as a bit of a
language pedant, I did notice...
Ken
next prev parent reply other threads:[~2009-09-02 18:17 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-01 6:23 more compilation failures: -DSCM_DEBUG_TYPING_STRICTNESS=2 Ken Raeburn
2009-09-01 6:26 ` Ken Raeburn
2009-09-16 19:20 ` Andy Wingo
2009-11-18 5:52 ` Ken Raeburn
2009-11-18 9:37 ` Ludovic Courtès
2009-11-18 20:40 ` Ken Raeburn
2009-11-18 21:18 ` Andy Wingo
2009-11-18 23:09 ` Ludovic Courtès
2009-09-01 19:47 ` Ludovic Courtès
2009-09-01 22:29 ` Ken Raeburn
2009-09-02 8:08 ` Ludovic Courtès
2009-09-02 18:17 ` Ken Raeburn [this message]
2009-09-03 11:48 ` Ludovic Courtès
2009-09-08 23:37 ` Neil Jerram
2009-09-09 1:41 ` Ken Raeburn
-- strict thread matches above, loose matches on Subject: below --
2009-09-01 4:52 Ken Raeburn
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=B36B297C-7383-4D25-9DD2-FD31E4C23AEB@raeburn.org \
--to=raeburn@raeburn.org \
--cc=guile-devel@gnu.org \
--cc=ludo@gnu.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).