From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Marius Vollmer Newsgroups: gmane.lisp.guile.devel Subject: Re: SCM_PTR_LE ? Date: 01 Aug 2002 18:40:46 +0200 Sender: guile-devel-admin@gnu.org Message-ID: References: <15682.60268.422843.138038@blauw.xs4all.nl> <15687.4663.59228.939494@blauw.xs4all.nl> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1028220094 11252 127.0.0.1 (1 Aug 2002 16:41:34 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 1 Aug 2002 16:41:34 +0000 (UTC) Cc: guile-devel@gnu.org Return-path: Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17aJ12-0002vD-00 for ; Thu, 01 Aug 2002 18:41:32 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17aJ1X-0001Xj-00; Thu, 01 Aug 2002 12:42:03 -0400 Original-Received: from krusty.dt.e-technik.uni-dortmund.de ([129.217.163.1] helo=mail.dt.e-technik.uni-dortmund.de) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17aJ0v-0001Vc-00 for ; Thu, 01 Aug 2002 12:41:25 -0400 Original-Received: from burns.dt.e-technik.uni-dortmund.de (burns.dt.e-technik.uni-dortmund.de [129.217.163.19]) by mail.dt.e-technik.uni-dortmund.de (Postfix) with ESMTP id AE852A3831; Thu, 1 Aug 2002 18:41:23 +0200 (CEST) Original-Received: by burns.dt.e-technik.uni-dortmund.de (Postfix, from userid 520) id 4D71C2613B; Thu, 1 Aug 2002 18:40:47 +0200 (CEST) Original-To: hanwen@cs.uu.nl In-Reply-To: <15687.4663.59228.939494@blauw.xs4all.nl> Original-Lines: 55 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 Errors-To: guile-devel-admin@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.devel:916 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:916 Han-Wen writes: > marius.vollmer@uni-dortmund.de writes: > > Han-Wen writes: > > > > > Can anyone explain to me why for the love of god, we have _macros_ to > > > compare pointers? (i.e. SCM_PTR_LT, SCM_PTR_GE) ? SCM sources > > > indicate that this is to support Turbo C running in protected mode on > > > i386. > > > > > > I suggest it be scrapped. > > > > Hmm. The macros look like a potentially useful abstraction to me. We > > are not making use of it right now, but it wouldn't feel right to just > > remove them and thereby destroy information. > > I think that pointer comparison is pretty well defined in ANSI C; can > you think of a solid reason to support them? What is that definition? I think ANSI C only defines the outcome of comparisons for pointers that point into the same object, i.e., the same array or a single block returned from malloc. A consequence would be that you can not reliably test whether a pointer does point into some object, since the results are not defined when it points outside. For example, is the following guaranteed to print "sane"? char block1[100]; char block2[100]; char *ptr = block1 + 50; if (ptr >= block2 && ptr < block2+100) printf ("sane\n"); else printf ("insane\n"); I don't know. > Not that this one instance bugs in particular, but the GUILE source > code is full of these so called "abstractions" that don't solve any > existing problem, and just make the source code hard to read and > debug. I think we can not have too little unnecessary abstractions. Agreed. I'm not convinced yet that the PTR_LT abstractions is really unnecessary. I can understand the urge to go in and just rewrite the whole thing so that it be pretty. The main reason I don't write much kernel code is the crappy coding style of Linux. (Not really.) Also, it is hard to maintain seemingly useless abstractions while writing new code. We can probably get away without using SCM_PTR_LT properly in the future, but maybe it will come back and bite us. You have just introduced the SCM_WRITABLE_VELTS abstraction which is at present also unnecessary, but it might become critical in the future. Anyway, pending the ANSI C issue above, I'm actually sympathetic to removing of SCM_PTR_LT. It really feels a bit silly. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel