lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 16 May 2017 10:27:46 +0200 From: Michal Hocko <mhocko@...nel.org> To: Nick Desaulniers <nick.desaulniers@...il.com> Cc: akpm@...ux-foundation.org, hannes@...xchg.org, mgorman@...hsingularity.net, vbabka@...e.cz, minchan@...nel.org, linux-mm@...ck.org, linux-kernel@...r.kernel.org Subject: Re: [Patch v2] mm/vmscan: fix unsequenced modification and access warning I have discussed this with our gcc guys and here is what they say: On Wed 10-05-17 10:38:44, Michal Hocko wrote: [...] > But I > still do not understand which part of the code is undefined and why. My > reading and understanding of the C specification is that > struct A { > int a; > int b; > }; > > struct A f = { .a = c = foo(c), .b = c}; > > as long as foo(c) doesn't have any side effects because because .a is > initialized before b and the assignment ordering will make sure that c > is initialized before a. > > 6.7.8 par 19 (ISO/IEC 9899) > 19 The initialization shall occur in initializer list order, each > initializer provided for a particular subobject overriding any > previously listed initializer for the same subobject; all subobjects > that are not initialized explicitly shall be initialized implicitly > the same as objects that have static storage duration. > > So is my understanding of the specification wrong or is this a bug in > -Wunsequenced in Clang? : This is not the reason why the above is okay. The following part: : { .a = c = ..., .b = c } : is okay because there's a sequence point after each full expression, and : an initializer is a full expression, so there's a sequence point between : both initializers. The following part: : { ... c = foo(c) ... } : is okay as well, because there's a sequence point after evaluating all : arguments and before the actual call (otherwise the common 'i=next(i)' : idiom doesn't work). So both constructs that potentially could be sources : of sequence point violations actually aren't and hence okay. clangs : warning is invalid. I guess it is worth reporting this to clang bugzilla. Could you take care of that Nick? -- Michal Hocko SUSE Labs
Powered by blists - more mailing lists