Thank you for your detail information, and what you said sounds reasonable to me.
Send from Lenovo A788t. Jeff Epler <jep...@unpythonic.net> wrote: >On Wed, Nov 12, 2014 at 11:43:08PM +0800, Chen Gang wrote: >> > (I assume the >> > compiler could do things like replace an intended load from memory with >> > a constant load or even no load at all) >> > >> >> Excuse me, my English is not quite well, I can not understand what you >> said above. (If necessary, please help provide more details for it). > >I am concerned that writing regs[TREG_TP] is "undefined behavior" >according to the C standard. > >This expression is equivalent to *(regs + TREG_TP). The expression >(regs + TREG_TP) does not result in a pointer to any element of regs[], >so dereferencing it is undefined behavior. (Source: C99 draft standard >WG14/N1256, annex J.2, "[The behavior is undefined if t]he operand of >the unary * operator has an invalid value") > >That is why the compiler showed the original diagnostic, but the same >logic that made the loop's behavior undefined also makes the expression >regs[TREG_TP] undefined whereever it appears. > >None of this is a specific problem with your proposed patch. Rather, it >is a suggestion that the whole structure's design needs to be revisited >in light of compilers beginning to notice that regs[TREG_TP] is >undefined behavior and change their generated code as a result. > >Unfortunately it looks like this header is also a part of the userspace >API, so it can't simply be changed just in case all in-kernel uses are >changed. > >Jeff
