From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] Bindings for =?utf-8?B?4oCYc2VuZGZpbGXigJk=?= Date: Thu, 21 Mar 2013 01:24:02 -0400 Message-ID: <8738vpba19.fsf@tines.lan> References: <87ip4liufs.fsf@gnu.org> <878v5hbblk.fsf@tines.lan> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1363843866 18240 80.91.229.3 (21 Mar 2013 05:31:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 21 Mar 2013 05:31:06 +0000 (UTC) Cc: guile-devel@gnu.org To: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Mar 21 06:31:30 2013 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 1UIY66-0005Bq-8X for guile-devel@m.gmane.org; Thu, 21 Mar 2013 06:31:30 +0100 Original-Received: from localhost ([::1]:53949 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIY5i-0002YG-Td for guile-devel@m.gmane.org; Thu, 21 Mar 2013 01:31:06 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:37219) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIY5f-0002Y4-Pg for guile-devel@gnu.org; Thu, 21 Mar 2013 01:31:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UIXz7-0006zX-DF for guile-devel@gnu.org; Thu, 21 Mar 2013 01:25:18 -0400 Original-Received: from world.peace.net ([96.39.62.75]:43765) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIXz7-0006xR-8x; Thu, 21 Mar 2013 01:24:17 -0400 Original-Received: from 209-6-91-212.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([209.6.91.212] helo=tines.lan) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UIXyz-00021M-Nj; Thu, 21 Mar 2013 01:24:09 -0400 In-Reply-To: <878v5hbblk.fsf@tines.lan> (Mark H. Weaver's message of "Thu, 21 Mar 2013 00:50:15 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 96.39.62.75 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:15943 Archived-At: Mark H Weaver writes: >> + for (result = 0, left = c_count; result < c_count; ) > > If 'c_count's does not fit in a 'ssize_t', then this loop will go > forever and 'result' will wrap around to negative numbers and undefined > C behavior. Having just consulted the relevant C standards, I see that I was wrong to claim that the loop will spin forever. If a signed integer is compared with an unsigned integer of equal rank, the signed integer is converted to unsigned first. The latter part of my statement (about undefined behavior) was true, and invalidates any other predictions. If 'result' overflows (and it will if 'c_count' does not fit in a 'ssize_t' and nothing else goes wrong) then the behavior of the program is completely undefined. Modern C compilers are increasingly fond of taking advantage of that fact, as demonstrated by the recent discovery that they were optimizing out our overflow checks. http://stackoverflow.com/questions/14495636/strange-multiplication-behavior-in-guile-scheme-interpreter http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commit;h=2355f01709eadfd5350c510cdb095b4e3f71f17c Mark