Re: [Xen-devel] [PATCH v4 8/8] ioreq-server: bring the PCI hotplug controller implementation into Xen

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Jan Beulich writes ("RE: [PATCH v4 8/8] ioreq-server: bring the PCI hotplug 
controller implementation into Xen"):
> On 09.04.14 at 15:42, <Paul.Durrant@xxxxxxxxxx> wrote:
> > Personally I find using forward jumps to fail labels the most
> > readable form of error exit - I wish they were used more widely.
> 
> Interesting - almost everyone/-thing involved in educating me in
> programming skills recommended to try to get away without goto
> altogether, unless programming Fortran, Basic or some such.

I think the hatred of goto is a "lie to children".  It is easy to
misuse goto and make spaghetti.

My view is that use of goto should normally be restricted to certain
very specific patterns.  Examples:
  * Providing a uniform cleanup path (eg error exit) from a function
  * "goto continue_foobar" or "goto break_foobar" for emulating
    "continue" or "break" on an outer loop from within an inner loop
  * Usages embedded in structural macros

Certainly goto should not be used if another control construct can do
the job (without excessive circumlocution or repetition).  In libxl we
have a few "goto retry_transaction" which I think should be abolished.
IME goto should not be used to construct loops.

But goto _should_ be used to avoid repetition.  The exit path pattern
is a particularly good example.  In functions which use this pattern:
  - all variables which refer to resources are initialised to
    "unallocated" (0, -1, whatever) at declaration
  - there is only one use of "return"
  - the return is preceded by a single copy of the cleanup for
    all the allocated resources
The result is that it is difficult to accidentally leak or
double-free resources.  Failure to initialise one of the resource
variables to "empty" is normally detected by the compiler.

In this pattern the label should have a conventional name.  In libxl
we use "out".

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel