From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Concurrency has landed Date: Thu, 22 Dec 2016 11:23:34 -0800 Organization: UCLA Computer Science Department Message-ID: <9b3d4460-dae9-86a4-88d8-61944b485ce1@cs.ucla.edu> References: <83oa0lgnzx.fsf@gnu.org> <83inqrfzzp.fsf@gnu.org> <83a8c3fxru.fsf@gnu.org> <0bcf38b7-0893-a300-39c3-32da985c5717@cs.ucla.edu> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1482434637 23474 195.159.176.226 (22 Dec 2016 19:23:57 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 22 Dec 2016 19:23:57 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 Cc: Eli Zaretskii , emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 22 20:23:53 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cK8xs-0004V1-C4 for ged-emacs-devel@m.gmane.org; Thu, 22 Dec 2016 20:23:44 +0100 Original-Received: from localhost ([::1]:35876 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cK8xw-0004nx-Uh for ged-emacs-devel@m.gmane.org; Thu, 22 Dec 2016 14:23:48 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37291) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cK8xr-0004nq-7f for emacs-devel@gnu.org; Thu, 22 Dec 2016 14:23:44 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cK8xq-0004GP-6L for emacs-devel@gnu.org; Thu, 22 Dec 2016 14:23:43 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:54632) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cK8xm-0004FL-FY; Thu, 22 Dec 2016 14:23:38 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id B4E1E1600BB; Thu, 22 Dec 2016 11:23:35 -0800 (PST) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id etTlpB4dkSJP; Thu, 22 Dec 2016 11:23:35 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 096441600BD; Thu, 22 Dec 2016 11:23:35 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id MD99CJzJD3DZ; Thu, 22 Dec 2016 11:23:34 -0800 (PST) Original-Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id E27991600BB; Thu, 22 Dec 2016 11:23:34 -0800 (PST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 131.179.128.68 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:210740 Archived-At: On 12/21/2016 08:52 PM, Daniel Colascione wrote: >> reasons, but also because the byte stack implementation relies on >> using pointers to freed storage, which violates the C > How? If memory serves, the code has several pointers p, q, r, ... into a memory region based at b that it wants to move. It then does the equivalent of 'b1 = realloc (b, newsize); p += b1-b; q += b1-b; r += b1-b; ...; b = b1;'. The C standard does not allow this: a program is not allowed to look at a pointer to freed storage (even if it does not dereference the pointer), which means the expression 'b1-b' has undefined behavior. Possibly my memory is wrong and realloc was not involved. Regardless, the code in question does not work with -fcheck-pointer-bounds, and it's confusing to rely on pointers to freed storage, even if you don't dereference them and the code happens to work. Also, the byte stack isn't needed so we might as well remove it.