From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.lisp.guile.devel Subject: Re: more compilation failures: -DSCM_DEBUG_TYPING_STRICTNESS=2 Date: Wed, 2 Sep 2009 14:17:49 -0400 Message-ID: References: <87bplu4fbr.fsf@gnu.org> <877hwheplm.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v936) Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1251915527 21996 80.91.229.12 (2 Sep 2009 18:18:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 2 Sep 2009 18:18:47 +0000 (UTC) Cc: guile-devel@gnu.org To: =?ISO-8859-1?Q?Ludovic_Court=E8s?= Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Sep 02 20:18:40 2009 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MiuPh-0005Yu-IL for guile-devel@m.gmane.org; Wed, 02 Sep 2009 20:18:33 +0200 Original-Received: from localhost ([127.0.0.1]:57093 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MiuPg-0003pW-Rd for guile-devel@m.gmane.org; Wed, 02 Sep 2009 14:18:32 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MiuPJ-0003bP-Fo for guile-devel@gnu.org; Wed, 02 Sep 2009 14:18:09 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MiuPF-0003ao-0n for guile-devel@gnu.org; Wed, 02 Sep 2009 14:18:09 -0400 Original-Received: from [199.232.76.173] (port=48007 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MiuPE-0003aj-U9 for guile-devel@gnu.org; Wed, 02 Sep 2009 14:18:04 -0400 Original-Received: from splat.raeburn.org ([69.25.196.39]:61126 helo=raeburn.org) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MiuP4-0005Do-HW; Wed, 02 Sep 2009 14:18:02 -0400 Original-Received: from [10.0.0.172] (squish.raeburn.org [10.0.0.172]) by raeburn.org (8.14.3/8.14.1) with ESMTP id n82IHno6014611; Wed, 2 Sep 2009 14:17:50 -0400 (EDT) In-Reply-To: <877hwheplm.fsf@gnu.org> X-Mailer: Apple Mail (2.936) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:9254 Archived-At: On Sep 2, 2009, at 04:08, Ludovic Court=E8s wrote: >> In the Guile case, I'm a tiny bit concerned about some of the =20 >> 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 =20 >> 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* -> =20 (u)intptr_t -> void*. So any value originally derived from a valid =20 pointer will work, but arbitrary values may not. Also, C99 talks =20 about uintptr_t as being capable of holding a converted pointer-to-=20 void; strictly speaking, I don't think it requires that a direct =20 conversion from/to any other pointer type (except possibly char*) work =20= the same way. So, for example, uintptr_t may have 64 bits on a machine that uses 48-=20= bit pointers (segment+offset? also, some embedded processors have non-=20= power-of-two pointer or integer sizes, though I don't know whether =20 they have pointer and int types matching in size); pointers may have =20 trapping representations (invalid segment number?); storing an integer =20= value into a pointer register may cause certain bits to be masked off; =20= manipulation of pointer values in general registers may not preserve =20 bits known by the compiler not to be set in any valid or null =20 pointers; etc. And then there's the whole NULL-vs-0 thing -- "0" is a null pointer =20 constant in source code, but strictly speaking the compiler produces a =20= null pointer constant there; it doesn't imply that the null pointer =20 has the same binary representation as 0, nor that a non-constant zero =20= value when cast to a pointer will be a null pointer, nor that memset(,=20= 0,) gives you null pointers, nor that a null pointer cast to uintptr_t =20= will have the value 0, etc. (For example, in an architecture with one pointer format for segment + =20= word offset, and a second representation for segment + word offset + =20 bit offset into word, a void* may require the second form, but a =20 struct pointer might use the former, if all structs are required to be =20= word-aligned. And converting a pointer to uintptr_t could just copy =20 bits around, giving consistent results only if you use the same =20 pointer form consistently in the conversions. And all-bits-zero may =20 store an invalid segment number that could lead to a trap when loaded =20= into a pointer register, and a "null pointer" may be represented with =20= a reserved non-zero segment number. This is not completely =20 theoretical... I once used a platform with multiple pointer types and =20= a null pointer representation using segment number -1, which could be =20= loaded without faulting but not dereferenced, but I'm rusty on some of =20= 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 =20 likely to care about, will still meet these assumptions to the best of =20= my knowledge, so it's probably not a big problem. But as a bit of a =20 language pedant, I did notice... Ken=