From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1231 invoked by alias); 19 Aug 2004 06:37:36 -0000 Mailing-List: contact xconq7-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: xconq7-owner@sources.redhat.com Received: (qmail 1224 invoked from network); 19 Aug 2004 06:37:35 -0000 Received: from unknown (HELO mail3.panix.com) (166.84.1.74) by sourceware.org with SMTP; 19 Aug 2004 06:37:35 -0000 Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail3.panix.com (Postfix) with ESMTP id A5D19981C0; Thu, 19 Aug 2004 02:37:35 -0400 (EDT) Received: (from kingdon@localhost) by panix5.panix.com (8.11.6p2-a/8.8.8/PanixN1.1) id i7J6bZc03815; Thu, 19 Aug 2004 02:37:35 -0400 (EDT) Date: Thu, 19 Aug 2004 11:25:00 -0000 Message-Id: <200408190637.i7J6bZc03815@panix5.panix.com> From: Jim Kingdon To: hronne@comhem.se Cc: xconq7@sources.redhat.com In-reply-to: (message from Hans Ronne on Wed, 18 Aug 2004 14:53:15 +0200) Subject: Re: The border between fiction and reality References: X-SW-Source: 2004/txt/msg00955.txt.bz2 > However, a different situation arises with move-unit commands, all of which > eventually end up in advance_into_cell. At this point we are committed to > moving, and we have to know what real units are present in the destination > cell. Well, to me that means there should be an advance action, so that the decision between overrun and move (and the other choices, like capture) are in the action, rather than outside it. But perhaps there is a simpler solution, or the status quo is technically wrong but doesn't lead to any exploits/leaks/etc. Or even that advance_into_cell is tied into the user interfaces in ways which aren't immediately obvious to me, and thus would be hard to put into an action.