From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: prj@po.cwru.edu (Paul Jarc) Newsgroups: gmane.lisp.guile.devel Subject: Re: The relationship between SCM and scm_t_bits. Date: Sun, 23 May 2004 11:03:41 -0400 Organization: What did you have in mind? A short, blunt, human pyramid? Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: References: <40A6307C.9050809@dirk-herrmanns-seiten.de> <871xliq2p0.fsf@zagadka.ping.de> <40AE5A80.9050809@dirk-herrmanns-seiten.de> <40AEF7B3.2020707@dirk-herrmanns-seiten.de> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1085336921 17139 80.91.224.253 (23 May 2004 18:28:41 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 23 May 2004 18:28:41 +0000 (UTC) Cc: Marius Vollmer , guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun May 23 20:28:29 2004 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BRxi0-0002jO-00 for ; Sun, 23 May 2004 20:28:29 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BRxSL-0006xs-FG for guile-devel@m.gmane.org; Sun, 23 May 2004 14:12:17 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BRw1K-0004pp-19 for guile-devel@gnu.org; Sun, 23 May 2004 12:40:18 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BRvIU-0004Bk-Oj for guile-devel@gnu.org; Sun, 23 May 2004 11:54:30 -0400 Original-Received: from [129.22.104.46] (helo=mirapoint1.tis.cwru.edu) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1BRuVr-0003GJ-Jc for guile-devel@gnu.org; Sun, 23 May 2004 11:03:43 -0400 Original-Received: from multivac.cwru.edu (multivac.ITS.CWRU.Edu [129.22.114.26]) by mirapoint1.tis.cwru.edu (MOS 3.4.3-CR) with SMTP id BOB80091; Sun, 23 May 2004 11:03:42 -0400 (EDT) Original-Received: (qmail 19954 invoked by uid 500); 23 May 2004 15:04:03 -0000 Original-To: Dirk Herrmann In-Reply-To: <40AEF7B3.2020707@dirk-herrmanns-seiten.de> (Dirk Herrmann's message of "Sat, 22 May 2004 08:48:19 +0200") Mail-Copies-To: nobody Mail-Followup-To: Dirk Herrmann , guile-devel@gnu.org, Marius Vollmer Original-Lines: 41 User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.devel:3750 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:3750 Dirk Herrmann wrote: > This is highly academic. Within guile there are so many places where > we perform operations that are not defined according to the C > standard: conservative garbage collection, copying stacks for > continuations, assembly code, ... Well, my impression is that Marius wants to get rid of at least this particular bit of nonconformance. Marius? > Please explain, why you think that it is cleaner to say it only holds > scheme objects if in fact it does not. That's not exactly it. The words that hold Scheme values would be accessed using the SCM type, instead of coneverting to/from scm_t_bits. Other words, holding non-Scheme values, would still be accessed as scm_t_bits. (AIUI.) > The standard says that the result of casting pointers to scm_t_bits > to pointers to SCM gives implementation dependent results, right? Or > does the standard explicitly forbid such casts? Casting the pointer is ok in itself (well, unless there is an alignment mismatch). Accessing the pointed-to memory gives undefined behvaior if there isn't actually an object there of the type you're using to access it. If SCM were defined as a struct containing scm_t_bits, then it would certainly be legal to access an SCM object via scm_t_bits*. > What is the reason to change a paradigm, which has for several > years worked quite nicely, is easily understood, and has helped to > find and probably also to avoid a bunch of errors? Is there any > _real_ reason that any of you is facing, like that guile does not > compile or work on one of your machines? I think Marius is worried that there may be systems where the bits of an SCM value are different from the bits of the corresponding scm_t_bits value. I don't know whether any have actually been found. paul _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel