To be clear, what I patched up last Friday shouldn't run into this issue and it's ready for review.
On Mon, Nov 23, 2015 at 12:58 PM, Barret Rhoden <[email protected]> wrote: > On 2015-11-19 at 20:52 "'Davide Libenzi' via Akaros" > <[email protected]> wrote: >> IMO, all the local variable accessed within a waserror() return path, >> and (re)assigned after the waserror(), must be marked as volatile. >> Or bad things happen. > > absolutely. the canonical example is in devwalk: > > struct walkqid *devwalk(struct chan *c, > struct chan *nc, char **name, int nname, > struct dirtab *tab, int ntab, Devgen * gen) > { > ERRSTACK(1); > int i, j; > volatile int alloc; /* to keep waserror from optimizing this out > */ > struct walkqid *wq; > > > that was a case where bad things were happening. > > >> Let me rephrase my last statement: >> >> "IMO, on top of volatile, it would be wise not to assume, within the >> waserror section, that the values written into variables after it, >> will stick." > > that's a great rule. > > barret > > > -- > You received this message because you are subscribed to the Google Groups > "Akaros" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- ~Kevin -- You received this message because you are subscribed to the Google Groups "Akaros" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
