On Fri, Mar 26, 2021 at 07:24:32AM -0400, Dave Voutila wrote:
>
> Theo Buehler writes:
>
> > On Thu, Mar 25, 2021 at 08:07:53PM +0100, Preben Guldberg wrote:
> >> Dave Voutila wrote:
> >> > Preben Guldberg writes:
> >> > > The patch below addresses an off-by-one error reading argv when
> >> > > gen
On Fri, Mar 26, 2021 at 07:24:32AM -0400, Dave Voutila wrote:
>
> Theo Buehler writes:
>
> > On Thu, Mar 25, 2021 at 08:07:53PM +0100, Preben Guldberg wrote:
> >> Dave Voutila wrote:
> >> > Preben Guldberg writes:
> >> > > The patch below addresses an off-by-one error reading argv when
> >> > > g
Dave Voutila writes:
> Theo Buehler writes:
>
>> On Thu, Mar 25, 2021 at 08:07:53PM +0100, Preben Guldberg wrote:
>>> Dave Voutila wrote:
>>> > Preben Guldberg writes:
>>> > > The patch below addresses an off-by-one error reading argv when
>>> > > generating the error message.
>>>
>>> > > I pers
Theo Buehler writes:
> On Thu, Mar 25, 2021 at 08:07:53PM +0100, Preben Guldberg wrote:
>> Dave Voutila wrote:
>> > Preben Guldberg writes:
>> > > The patch below addresses an off-by-one error reading argv when
>> > > generating the error message.
>>
>> > > I personally find it clearer if the co
Theo Buehler wrote:
> However, I think the current logic is both wrong and the wrong way
> around. I believe the following is much clearer. It doesn't have a dead
> else branch and it deletes 'ret', so it doesn't use it uninitialized when
> checking 'res->action == CMD_STOPALL && ret != -1' (e.g.
On Thu, Mar 25, 2021 at 08:07:53PM +0100, Preben Guldberg wrote:
> Dave Voutila wrote:
> > Preben Guldberg writes:
> > > The patch below addresses an off-by-one error reading argv when
> > > generating the error message.
>
> > > I personally find it clearer if the condition of mixing -a with an id
Dave Voutila wrote:
> Preben Guldberg writes:
> > The patch below addresses an off-by-one error reading argv when
> > generating the error message.
> > I personally find it clearer if the condition of mixing -a with an id
> > is highlighted. I included a suggestion in the patch below.
> Since -a
Preben Guldberg writes:
> Thanks to Dave, Theo and Klemens for accepting my previous patch
>
> In other tests, I noticed the following error:
>
> % vmctl stop -a testvm
> vmctl: invalid id: (null)
>
> The patch below addresses an off-by-one error reading argv when
> generating the error
Thanks to Dave, Theo and Klemens for accepting my previous patch
In other tests, I noticed the following error:
% vmctl stop -a testvm
vmctl: invalid id: (null)
The patch below addresses an off-by-one error reading argv when
generating the error message.
I personally find it clearer if
