From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.devel Subject: Re: RFC: Foreign objects facility Date: Sun, 27 Apr 2014 19:51:41 +0200 Message-ID: <87oazm3bki.fsf@pobox.com> References: <87bnvm52u6.fsf@pobox.com> <87a9b692ys.fsf@yeeloong.lan> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1398621126 11711 80.91.229.3 (27 Apr 2014 17:52:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 27 Apr 2014 17:52:06 +0000 (UTC) Cc: guile-devel To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Apr 27 19:52:01 2014 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WeTFA-0008Ll-5L for guile-devel@m.gmane.org; Sun, 27 Apr 2014 19:52:00 +0200 Original-Received: from localhost ([::1]:40146 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WeTF9-0001Qf-Lx for guile-devel@m.gmane.org; Sun, 27 Apr 2014 13:51:59 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59706) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WeTF2-0001Pi-EJ for guile-devel@gnu.org; Sun, 27 Apr 2014 13:51:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WeTEx-0001IO-Hr for guile-devel@gnu.org; Sun, 27 Apr 2014 13:51:52 -0400 Original-Received: from a-pb-sasl-quonix.pobox.com ([208.72.237.25]:37059 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WeTEx-0001II-Bz for guile-devel@gnu.org; Sun, 27 Apr 2014 13:51:47 -0400 Original-Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id BE4D210E90; Sun, 27 Apr 2014 13:51:46 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=sasl; bh=z0v+XbA2DSyaY+QXkZf+3O3UD20=; b=Sdhthi ZX/7QbnDL4Y2OYebHDin5FEA0L2XlKvHSJFjmkSMQ6IQ8nxfMhFOW4H2KM/fibMJ 7QbYYwk6WNVOwUbhyx6xFKrLsw27SoXdeQ9QoQPLsh32mydbZxNYFOUMb0WkHF2I 2w1aF9RWjC77SswdWGRxAA5hgSEsvSLGFsYPQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; q=dns; s=sasl; b=TB0qgkaKmE6/sNtYsRQijhzdDsEpshHR RxPc4j5njwjAYcr6kQlRU1w5pgQIyaC1jJOJhddlsLMssITLlA/V8R0PT8aW9XaB s/fwov3ve/+ybeyuo0xb8RyaFyv1XXnwXfvVxULRGREBlnBQ4SXdWiCYVR7nMZBn q/vZkzf+lAQ= Original-Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id B6E3310E8F; Sun, 27 Apr 2014 13:51:46 -0400 (EDT) Original-Received: from badger (unknown [88.160.190.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 536CD10E8E; Sun, 27 Apr 2014 13:51:44 -0400 (EDT) In-Reply-To: <87a9b692ys.fsf@yeeloong.lan> (Mark H. Weaver's message of "Sun, 27 Apr 2014 12:00:59 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-Pobox-Relay-ID: 98A15ED4-CE34-11E3-88BA-6F330E5B5709-02397024!a-pb-sasl-quonix.pobox.com X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 208.72.237.25 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 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 Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:17107 Archived-At: Hi Mark, Thanks for the review! On Sun 27 Apr 2014 18:00, Mark H Weaver writes: > Andy Wingo writes: > >> Here is the proposed C API: >> >> SCM scm_make_foreign_object_type (SCM name, SCM slot_names, >> scm_t_struct_finalize finalizer); > > Shouldn't it be 'scm_t_struct_finalizer', with trailing 'r'? Probably it should, but note that it's already defined -- see struct.h. (My bad there, I think!) >> SCM scm_make_foreign_object_n (SCM type, size_t n, scm_t_bits vals[]); >> >> scm_t_bits scm_foreign_object_ref (SCM obj, size_t n); >> void scm_foreign_object_set_x (SCM obj, size_t n, scm_t_bits val); > > I'm worried about the type-punning that's implied by this interface. This issue exists already with the SMOB and struct interfaces. I don't think that the proposed API adds new hazards, though it does extend the old ones. > The C standards are now very strict about this sort of thing, It's an incredible shame that C is making itself semantically less capable as time goes on :-( > For example, having recently researched this, I know that converting > unsigned integers to signed integers is very awkward and potentially > inefficient to do portably, so using 'scm_foreign_object_ref' to extract > a signed integer will be a pain. It would look something like this > (untested): > > scm_t_signed_bits > scm_foreign_object_signed_ref (SCM obj, size_t n) > { > scm_t_bits bits = scm_foreign_object_ref (obj, n); > > /* GNU C specifies that when casting to a signed integer of width N, the > value is reduced modulo 2^N to be within range of the type. Neither > C99 nor C11 make any guarantees about casting an out-of-range value > to a signed integer type. */ > > #ifndef __GNUC__ > if (bits > SCM_T_SIGNED_BITS_MAX) > return -1 - (scm_t_signed_bits) ~bits; > #endif > return (scm_t_signed_bits) bits; > } True sadness. > Portability is more problematic for pointer types. The C standards make > no guarantees about the semantics of converting between pointers and > integers, and it's not clear to me how future proof this will be. Don't they make some guarantees wrt uintptr_t and intptr_t ? > One related issue is that I'd like to leave open the possibility that > 'scm_t_bits' might be larger than a pointer. You prefer to have three interface then: one for uintptr_t, one for intptr_t, and one for void*? > For constructors, I think we should provide a macro that handles the > conversion from pointer to scm_t_bits. (Converting from signed to > unsigned is portable, so there's no issue there). This is really gross... >> The overhead of a foreign object is two words -- the same as the >> overhead on any struct. (Compare to SMOBs, which have a half-word >> overhead.) > > It would be good to think about how we might someday reduce this > overhead in the future, and to make sure we don't make decisions that > would prevent us from doing that. This is an orthogonal issue, I think, and would like to punt on that for now. >> + scm_t_bits vals[2] = { val0, val1 }; > > This non-constant initializer depends on C99. Will fix. >> + if (scm_i_symbol_ref (layout, i * 2) != 'u') >> + scm_wrong_type_arg_msg (FUNC_NAME, 0, layout, "'u' field"); > > This looks inefficient. How about using 'scm_i_symbol_chars'? OK. Cheers, Andy -- http://wingolog.org/