Date: Tue, 9 Oct 2012 13:50:24 -0400 From: Eitan Adler <eadler@freebsd.org> To: David Chisnall <theraven@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Andrey Chernov <ache@freebsd.org> Subject: Re: svn commit: r241373 - head/lib/libc/stdlib Message-ID: <CAF6rxgnR%2Bqr0jEqKtSBKcE0oAESrwGKQED%2BN7LJSfUeuGryRYw@mail.gmail.com> In-Reply-To: <977E1107-46D4-476F-A04D-AEFD87D1DE53@FreeBSD.org> References: <201210091425.q99EPFS6020787@svn.freebsd.org> <507451DE.9060909@freebsd.org> <977E1107-46D4-476F-A04D-AEFD87D1DE53@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 9 October 2012 13:16, David Chisnall <theraven@freebsd.org> wrote: > On 9 Oct 2012, at 17:33, Andrey Chernov wrote: > >> Do you check assembler output for _both_ cases? >> In my testing clang and gcc xor's 'junk' properly in case it have >> 'volatile' keyword (as in srandomdev()) and elide it without 'volatile'. >> IMHO this change should be backed out for srandomdev() and adding >> 'volatile' for sranddev() instead. > > In it's original form, it is very dangerous - the whole expression reduces to undefined and so the LLVM IR for the call is: > > call void @srand(i32 undef) > > The back end is then free to use any value for the call argument, including any register value or 0. In fact, the backend is free to jump to a random location and potentially kill kittens. There is *no* guarantee when it comes to undefined behavior. > Adding the volatile means that we are doing an XOR with a value left on the stack. If this is early on in the application, then it is most likely to be 0. If it's later on, then there may be a value here, but it's still not very likely to be something particularly unpredictable. volatile only helps by mistake because clang is overly aggressive is turning off optimizers. The code is still undefined. -- Eitan Adler Source & Ports committer X11, Bugbusting teams
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAF6rxgnR%2Bqr0jEqKtSBKcE0oAESrwGKQED%2BN7LJSfUeuGryRYw>