From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14307 invoked by alias); 18 Nov 2015 10:30:50 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 37135 Received: (qmail 29822 invoked from network); 18 Nov 2015 10:30:47 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 X-AuditID: cbfec7f4-f79026d00000418a-25-564c5354240a Date: Wed, 18 Nov 2015 10:30:38 +0000 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: Bug in alias expansion Message-id: <20151118103038.6eab1150@pwslap01u.europe.root.pri> In-reply-to: <151117205508.ZM26027@torch.brasslantern.com> References: <20151115200356.0f3a80a2@ntlworld.com> <20151117172951.01bf1825@pwslap01u.europe.root.pri> <151117205508.ZM26027@torch.brasslantern.com> Organization: Samsung Cambridge Solution Centre X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu) MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKLMWRmVeSWpSXmKPExsVy+t/xK7ohwT5hBnP38FscbH7I5MDoserg B6YAxigum5TUnMyy1CJ9uwSujJ7dF9gKvvJWTGxvZW9g7OXuYuTkkBAwkfi+sI0JwhaTuHBv PVsXIxeHkMBSRomeJZ/ZIZwZTBLP9s5ignC2MUq8mr+dFaSFRUBV4sfOiSwgNpuAocTUTbMZ QWwRAXGJs2vPg8WFBZQlVhyYwAxi8wrYS/Tu3w1WwylgJfHlUA/UhoeMEpP/fwa7g19AX+Lq 309QN9lLzLxyhhGiWVDix+R7YEOZBbQkNm9rYoWw5SU2r3kLtkBIQF3ixt3d7BMYhWYhaZmF pGUWkpYFjMyrGEVTS5MLipPScw31ihNzi0vz0vWS83M3MUIC98sOxsXHrA4xCnAwKvHwJiz2 DhNiTSwrrsw9xCjBwawkwvte1ydMiDclsbIqtSg/vqg0J7X4EKM0B4uSOO/cXe9DhATSE0tS s1NTC1KLYLJMHJxSDYw5rA1l0cm1odpRt7f1bH/BHb6ytvhn6tN9jevOXp4ctvR4f0H3x8Pn V8nO0//k0T+npfHA8fmz91U71bYsfml1N5nh0KFvys78Tn3rTt0uuro8NHHn/Pl2gtVZbfGO BQly/wV2SfPt6ayPyXr94kfb6ZAlF3gOSXY0+m/ePe/lr4syWje/Nz5QYinOSDTUYi4qTgQA cYBPZlgCAAA= On Tue, 17 Nov 2015 20:55:08 -0800 Bart Schaefer wrote: > (Of course 37128 and 37122 aren't mutually exclusive, we can apply > both; there's probably some other case where subscript parsing may > go wrong that's fixed by 37128.) 37128 is fixing a particular problem to do with assumptions about parsing that are no longer valid; for this, it is entirely irrelevant where the alias actually gets expanded. I haven't followed whether there is a visible bug as a consequence of the latter. > } It's not very efficient, and it still has the problem that if something > } funny happens to the length --- and I don't think there's any guarantee > } of length preservation built into the lexer even though it happens to > } work in the cases we've looked at so far --- then somebody's going to > } get hurt. > > I'm not following this stuff about the length -- it can't mean that the > length of the alias expansion is the same as the length of the aliased > token -- so to what does it refer? The code assumes that if you pass a string through parse_subscript(), or more accurately through dquote_parse(), then the sequence of characters that comes out maps one-to-one onto the sequence of characters that went in. For example, a ( turns into an Inpar, a " turns into a Dnull, and so on --- similarly to if you simply tokenised it character by character but with more context sensitivity. The change makes the alias expansion irrelevant to this --- we backtrack over that -- but the code still relies on this assumption. Given how much can now happen inside dquote_parse() (as we see here, if only as a side issue to the bug being fixed), this doesn't seem ideal. However, I don't know of a case where it fails. pws