[BusyBox] [PATCH] Read-only option for losetup.c

[Rainer Weikusat]

Jason Schoon <floydpink at gmail.com> writes:
> You would prefer he set a variable, broke out of the switch, then
> checked that variable to determine that he should break out of the
> while?
>
> All of this in code meant to be as compact as possible?
>
> I know GOTO's have a horrible rep,

As this apparently will not stop to invade my mail box on its own: The
so-called 'horrible reputation' of goto dates back to ancient FORTRAN
and a single paper by Dijkstra, which offered no better arguments than
(paraphrased quote) "Our abilities to understand processes evolving in
time are rather poor", which has a natural answer along the lines of
'Speak for yourself, man, and keep away from the stuff you cannot
do'. Not using this or that language construct has not yet stopped
anyone from making an intangible mess out of his code. For a nice
example, go to the prism54 driver in Linux, islpci_mgt.c, and look at
the 'receive' function (and that's still rather harmless). And then
compare the wait code with this variant:

static struct islpci_mgmtframe *
wait_for_response(islpci_private *priv)
{
#define wait_cycle_jiffies ((ISL38XX_WAIT_CYCLE * 10 * HZ) / 1000)
        
        unsigned cycles_left;
        struct islpci_mgmtframe *frame;

        frame = NULL;
        cycles_left = ISL38XX_MAX_WAIT_CYCLES;
        do {
                sleep_on_timeout(&priv->mgmt_wqueue, wait_cycle_jiffies);
                frame = xchg(&priv->mgmt_received, NULL);
                if (frame) break;

                if (cycles_left > 1) {
                        /* it is unclear what this is supposed to accomplish */
                        printk(KERN_WARNING "PRISM54: minor timeout --"
                               " triggering device\n");
                        islpci_trigger(priv);
                }
        } while (--cycles_left);

        return frame;

#undef wait_cycle_jiffies       
}

I would second a ban on pointless comments, though :->.