Superflouous memcpy() in vmctl/main.c

Looking through the code for vmctl, I came across a repeated memcpy() in vmctl/main.c. In the checks below, ret is either set by a memcpy() or defaulted to 0. If set by memcpy(), and ret != 0, the memcpy() is repeated verbatim, which seems unnecessary. diff 09b708f572d76de8db7f7948ea7359b19bbd1

Re: vmctl: off-by-one error handling mixing -a with a VM id

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.

Re: vmctl: off-by-one error handling mixing -a with a VM 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 t

vmctl: off-by-one error handling mixing -a with a VM id

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

vmctl status does not reflect the stopping state of a VM

In "vmctl status", VMs that are being stopped but are still running will simply show up as "running". The diff below gives preference to showing the stopping state akin to how a paused VM is handled. Index: usr.sbin/vmctl/vmctl.c ===