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: i guess we're frozen & stuff Date: Tue, 11 Aug 2009 14:14:19 -0400 Message-ID: References: <8763cuwdkl.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v936) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1250014488 7562 80.91.229.12 (11 Aug 2009 18:14:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 11 Aug 2009 18:14:48 +0000 (UTC) Cc: =?ISO-8859-1?Q?Ludovic_Court=E8s?= , guile-devel@gnu.org To: Greg Troxel Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Aug 11 20:14:41 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 1Mavrt-0006L7-0t for guile-devel@m.gmane.org; Tue, 11 Aug 2009 20:14:41 +0200 Original-Received: from localhost ([127.0.0.1]:34986 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mavrr-0001MG-BE for guile-devel@m.gmane.org; Tue, 11 Aug 2009 14:14:39 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mavrp-0001LM-3J for guile-devel@gnu.org; Tue, 11 Aug 2009 14:14:37 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mavrk-0001Fw-EF for guile-devel@gnu.org; Tue, 11 Aug 2009 14:14:36 -0400 Original-Received: from [199.232.76.173] (port=54524 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mavrk-0001Ft-83 for guile-devel@gnu.org; Tue, 11 Aug 2009 14:14:32 -0400 Original-Received: from splat.raeburn.org ([69.25.196.39]:58948 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 1MavrZ-0005zt-No; Tue, 11 Aug 2009 14:14:29 -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 n7BIEKWR010520; Tue, 11 Aug 2009 14:14:20 -0400 (EDT) In-Reply-To: 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:9074 Archived-At: On Aug 11, 2009, at 13:04, Greg Troxel wrote: > So it seems that NULL is expanding to (void *) 0, and "sizeof (void *) > 0" is not legit. AFAIK sizeof is specified to work on variables and > types, and NULL is neither a variable nor a type. No, sizeof should work fine on expression values as well. I'm not quite sure about the question of syntax here -- sizeof's operand may be "an expression or the parenthesized name of a type". (So "sizeof var" is just a special case of the expression version, and doesn't require parentheses.) But if the expression starts with a parenthesized type because it's a cast... looking at the grammar, I'd think it would be valid, but that would have implications for code such as "sizeof (unsigned long) + 3" ... is that a single expression (3UL) you're taking the size of, or a sum involving the size of a type? Certainly "sizeof ((void *)0)", with the extra parens, works, and I think I've nearly always seen pointer versions of "NULL" using the enclosing parentheses, perhaps because of just this issue. Assuming "sizeof (TYPE) EXPR" isn't valid, I'd call it a defect in your system's definition of NULL, though I wouldn't go so far as to call it non-compliant. One could also argue that an expression provided to sizeof should always be parenthesized unless you know the syntax of it won't be altered by sticking "sizeof" in front, e.g., "sizeof(3+4)" instead of "sizeof 3+4". However, they're testing for a POSIX 2008 requirement that C99 and POSIX 2004 implementations need not meet, namely that NULL be of type "void *" instead of any null pointer constant (e.g., "0"). I think requiring POSIX 2008 support for Guile and anything that builds on it seems like a bad idea. I haven't looked at the libunistring code to see why it might be relevant, but it seems like a pretty gratuitous imposition to me. The only benefit of it I can see is that a variadic function can then take NULL as an argument without casting to char*; is that worth refusing to support other systems? > Is NULL something else on Linux? I'm not sure if it's GNU libc or GCC, but I'm getting "((void *)0)". Ken