public inbox for xconq7@sourceware.org
 help / color / mirror / Atom feed
From: Hans Ronne <hronne@comhem.se>
To: Eric McDonald <mcdonald@phy.cmich.edu>
Cc: xconq7@sources.redhat.com
Subject: Re: Major bug and what to do about it (long)
Date: Tue, 17 Aug 2004 23:42:00 -0000	[thread overview]
Message-ID: <l03130302bd483fae0dd7@[212.181.162.155]> (raw)
In-Reply-To: <Pine.LNX.4.44.0408171653220.32056-100000@leon.phy.cmich.edu>

>> The exploits are an interface problem. By eliminating the cause of the
>> problem (the ability to attempt bogus actions) you fix all possible
>> exploits in one stroke.
>
>I don't think that killing the patient is a good way to cure the
>diesease. Can we please just keep existing functionality while
>fixing the problems with it, instead of ripping out functionality
>as a way of fixing the problems?

I don't consider the ability to attempt bogus actions a functionality but a
bug, and I think we both agree on that. What I am suggesting is a solution
that will fix these problems forever. Just like putting wrapx on the
accessor macros fixed all the wrapping bugs.

>Properly dealing with bogus actions does not (or should not)
>entail removing two actions.

I am not suggesting that. I am suggesting that a fire-at action without a
valid target should be converted into (default into) a fire-into action.
See point 3 on my agenda.

>Hans, I think a lot of our disagreement stems from which working
>definition of 'fire-into' we are using. By 'fire-into' do you mean
>fire and hit the first unit in the stack or a randomly (possibly
>weighted by size) chosen unit from the stack? Or, do you mean that
>there is a real possibility that nothing is hit even if there is a
>stack of units in the cell? I have been arguing thinking that you
>are working from the former definition, but have been urging that
>we adopt the latter one.

As I stated previously (point 4 in my agenda), I would like to change how
fire-into works. I don't like the current situation where you get a free
shot at all units in the stack for just one acp. What I would like to have
is an action where you fire at the cell, one unit is picked as the target,
and you either hit or miss that unit. The logic behind this would be that
the shell has to land somewhere in the cell, and only one unit can sit
where it lands. So yes, it would certainly be possible to do a fire-into
action and not hit a single unit.

I don't think that this a necessary preconditon for fixing the other bugs,
though. I favour a step-by-step procedure.

Hans


  reply	other threads:[~2004-08-17 23:36 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-16 21:53 Hans Ronne
2004-08-16 22:14 ` Eric McDonald
2004-08-16 22:43   ` Hans Ronne
2004-08-17  0:33     ` Hans Ronne
2004-08-17  1:13       ` Eric McDonald
2004-08-17  1:39         ` Hans Ronne
2004-08-17  2:21           ` Eric McDonald
2004-08-17  4:28           ` Jim Kingdon
2004-08-17  5:17             ` Hans Ronne
2004-08-17 18:00               ` Eric McDonald
2004-08-18  5:26               ` Jim Kingdon
2004-08-18 11:11                 ` Hans Ronne
2004-08-17 16:14             ` Eric McDonald
2004-08-17  0:35     ` Eric McDonald
2004-08-17  1:16       ` Hans Ronne
2004-08-17  1:46         ` Eric McDonald
2004-08-17  3:03           ` Hans Ronne
2004-08-17  3:56             ` Eric McDonald
2004-08-17  1:30 ` Eric McDonald
2004-08-17  2:52   ` Hans Ronne
2004-08-17  2:53     ` Eric McDonald
2004-08-17  4:42       ` Jim Kingdon
2004-08-17 16:37         ` Eric McDonald
2004-08-17  4:48       ` Hans Ronne
2004-08-17 16:42         ` Eric McDonald
2004-08-18 10:56         ` Jim Kingdon
2004-08-17 11:06 ` Stan Shebs
2004-08-17 15:29   ` Hans Ronne
2004-08-17 16:01     ` Hans Ronne
2004-08-17 18:57       ` Eric McDonald
2004-08-17 20:38         ` Hans Ronne
2004-08-17 21:55           ` Eric McDonald
2004-08-17 23:42             ` Hans Ronne [this message]
2004-08-18  0:49               ` Eric McDonald
2004-08-18  4:59                 ` Hans Ronne
2004-08-18 15:28                   ` Eric McDonald
2004-08-19  6:37                     ` Elijah Meeks
2004-08-19 12:46                       ` Hans Ronne
2004-08-19 16:46                       ` Eric McDonald
2004-08-19 13:09                     ` Hans Ronne
2004-08-19 16:05                       ` Eric McDonald
2004-08-19 20:09                         ` Hans Ronne
2004-08-19 23:37                           ` Eric McDonald
2004-08-20  1:42                             ` Hans Ronne
2004-08-20  3:29                               ` Clearing the Air (long) Eric McDonald
2004-08-20 15:26                                 ` Stan Shebs
2004-08-18  5:30         ` Major bug and what to do about it (long) Jim Kingdon
2004-08-18 12:52           ` Hans Ronne
2004-08-17 18:23     ` Eric McDonald
2004-08-17 18:47       ` Hans Ronne
2004-08-17 18:59         ` Eric McDonald
2004-08-17 19:39           ` Hans Ronne
2004-08-17 21:14             ` Eric McDonald

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='l03130302bd483fae0dd7@[212.181.162.155]' \
    --to=hronne@comhem.se \
    --cc=mcdonald@phy.cmich.edu \
    --cc=xconq7@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).