On 16/01/2020 18.10, Igor Mammedov wrote: > On Thu, 16 Jan 2020 17:43:30 +0100 > Thomas Huth <th...@redhat.com> wrote: > >> On 15/01/2020 16.07, Igor Mammedov wrote: >>> Signed-off-by: Igor Mammedov <imamm...@redhat.com> >>> --- >>> CC: ehabk...@redhat.com >>> --- >>> hw/core/numa.c | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/hw/core/numa.c b/hw/core/numa.c >>> index 3177066..47d5ea1 100644 >>> --- a/hw/core/numa.c >>> +++ b/hw/core/numa.c >>> @@ -718,7 +718,7 @@ void numa_complete_configuration(MachineState *ms) >>> /* Report large node IDs first, to make mistakes easier to spot */ >>> if (!numa_info[i].present) { >>> error_report("numa: Node ID missing: %d", i); >>> - exit(1); >>> + exit(EXIT_FAILURE); >>> } >>> } >>> >>> @@ -759,7 +759,7 @@ void numa_complete_configuration(MachineState *ms) >>> error_report("total memory for NUMA nodes (0x%" PRIx64 ")" >>> " should equal RAM size (0x" RAM_ADDR_FMT ")", >>> numa_total, ram_size); >>> - exit(1); >>> + exit(EXIT_FAILURE); >>> } >>> >>> if (!numa_uses_legacy_mem()) { >> >> Please don't. We've had exit(1) vs. exit(EXIT_FAILURE) discussions in >> the past already, and IIRC there was no clear conclusion which one we >> want to use. There are examples of changes to the numeric value in our >> git history (see d54e4d7659ebecd0e1fa7ffc3e954197e09f8a1f for example), >> and example of the other way round (see 4d1275c24d5d64d22ec4a30ce1b6a0 >> for example). >> >> Your patch series here is already big enough, so I suggest to drop this >> patch from the series. If you want to change this, please suggest an >> update to CODING_STYLE.rst first so that we agree upon one style for >> exit() ... otherwise somebody else might change this back into numeric >> values in a couple of months just because they have a different taste. > > Ok, will do. > > There are other patches that introduce new exit(EXIT_FAILURE), > is it fine to use that or should I stick to the style used in nearby code?
Since we don't have a consensus yet, I guess it's ok to use it ... but adapting to the surrounding code is also a good idea, of course. Thomas