From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.lisp.guile.user Subject: Re: Now that SCM type is a union... Date: Sun, 14 Aug 2011 22:04:19 -0400 Message-ID: <5AEFF052-CE05-4EF7-9D88-1007B07ADCC5@raeburn.org> References: <20110812124436.GA2223@ccellier.rd.securactive.lan> <74643390-9111-4086-B315-1D2F847A514B@raeburn.org> <87y5yxfqk4.fsf@pobox.com> <0F01A791-AEE9-49D5-BA9D-762C7DCF879B@raeburn.org> <87liuvg3e7.fsf@pobox.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1313373872 25906 80.91.229.12 (15 Aug 2011 02:04:32 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 15 Aug 2011 02:04:32 +0000 (UTC) Cc: guile-user@gnu.org To: Andy Wingo Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Mon Aug 15 04:04:28 2011 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QsmXT-0005FQ-P2 for guile-user@m.gmane.org; Mon, 15 Aug 2011 04:04:28 +0200 Original-Received: from localhost ([::1]:47278 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QsmXS-0006Nq-SJ for guile-user@m.gmane.org; Sun, 14 Aug 2011 22:04:26 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:55619) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QsmXQ-0006Nk-Dc for guile-user@gnu.org; Sun, 14 Aug 2011 22:04:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QsmXP-0004Ce-9L for guile-user@gnu.org; Sun, 14 Aug 2011 22:04:24 -0400 Original-Received: from mail-vx0-f169.google.com ([209.85.220.169]:36761) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QsmXP-0004CX-6r for guile-user@gnu.org; Sun, 14 Aug 2011 22:04:23 -0400 Original-Received: by vxj15 with SMTP id 15so4406379vxj.0 for ; Sun, 14 Aug 2011 19:04:22 -0700 (PDT) Original-Received: by 10.52.71.197 with SMTP id x5mr3135118vdu.305.1313373862107; Sun, 14 Aug 2011 19:04:22 -0700 (PDT) Original-Received: from [10.0.0.158] (c-24-128-48-142.hsd1.ma.comcast.net [24.128.48.142]) by mx.google.com with ESMTPS id es7sm1389926vdb.42.2011.08.14.19.04.20 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 14 Aug 2011 19:04:21 -0700 (PDT) In-Reply-To: <87liuvg3e7.fsf@pobox.com> X-Mailer: Apple Mail (2.1084) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.220.169 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:8713 Archived-At: On Aug 14, 2011, at 16:10, Andy Wingo wrote: >> * We should expect some Guile applications to be in C++. What >> versions of the C++ spec should Guile support? >=20 > Dunno. What do other languages have to do with Guile's C interface? > Specifically what does C++ have to do with this? (Serious question.) Most languages, nothing; they can't directly use the C headers, even if = there's another way to tell, for example, the GNU Ada compiler what the = Guile ABI looks like. C++ is another matter -- at least, the languages = are sufficiently compatible that people will try. And we've already got = the 'extern "C"' bits in libguile.h to help support it. The C++ compiler will treat the calls to extern "C" functions specially, = using different name-mangling techniques (and I think different = function-calling interfaces are even possible, but I'm not sure). But = the header still needs to be parsed as C++, and that's not always a = strict superset of the latest and greatest C spec. >=20 >> * Shouldn't there be testing to catch this? (C89 mode, C99 mode, >> different C++ specs, enabling various compiler warnings -- for >> whatever compiler is in use -- and make them fatal, any interesting >> ways one might want to use libguile in an application that might >> stress compatibility issues.) I mean automated testing, not just >> Cedric. :-) >=20 > Perhaps :) Interested volunteers are welcome to set this up :) I've done it before for other projects... you just need to add to the = test suite a few files to be compiled with certain compilers and = compiler options -- perhaps repeatedly with different options -- and = make sure they compile. If you want to get really fancy, link and run = some trivial programs, but generally compiling with lots of warning = options is good enough, at least for C. For GCC, for example, I'd start = with "gcc -Wall -Wextra -Werror -pedantic" and "g++ -Wall -Wextra = -Werror -pedantic", and add more interesting options from there, then = multiply that by the various "-std" options available; the Solaris = compiler has a different syntax for warning options, but it too can be = told to enable various warnings and make them errors. I'll see about setting up something simple... >=20 >>> I will take a look at this issue soonish, but your help (and = Cedric's) >>> in debugging it is most appreciated :) I would love to keep the = union >>> as the "normal" SCM definition, but that might not be possible. >>=20 >> Regardless of the validity, there are popular compilers out there now >> which do not support this, when used in modes people may need or want >> to use. The installed headers need to adhere to higher standards in >> terms of portability problems and warnings than the library source, >> where we can dictate some of the compiler options. >=20 > Agreed. And AFAIK there are some ABI differences for returning unions > versus returning uintptr_t, so unfortunately it can't be a question of > ifdefs in Guile's C interface, it seems. I'll work on this, but if = you > have any suggestions as to the proper fix, they are most welcome. I don't see anything really clean... separate macros (same value, = different syntax) for static initialization vs use in run-time evaluated = expressions might be one way to keep the union type. For non-GNU C89, = the latter could expand to the return value of a function call, which = sucks for performance but keeps the API and ABI intact. For GCC in = pedantic C89 mode, the __extension__ keyword will tell it to shut up = about intentionally-used GNU extensions. There are other places where = the union value won't be useable -- for example, case labels in switch = statements need integer values. If you want one macro for static initialization and for normal = expressions, I think it's got to be an arithmetic or pointer type....