From owner-freebsd-current@FreeBSD.ORG Fri Jun 11 21:04:15 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD660106564A for ; Fri, 11 Jun 2010 21:04:15 +0000 (UTC) (envelope-from tijl@coosemans.org) Received: from mailrelay011.isp.belgacom.be (mailrelay011.isp.belgacom.be [195.238.6.178]) by mx1.freebsd.org (Postfix) with ESMTP id 16DAF8FC14 for ; Fri, 11 Jun 2010 21:04:14 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQFAH1AEkxbsUyJ/2dsb2JhbACDHY9MjBJyrkKQUIEmgwNvBA Received: from 137.76-177-91.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([91.177.76.137]) by relay.skynet.be with ESMTP; 11 Jun 2010 23:04:12 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.4/8.14.4) with ESMTP id o5BL4BFJ018663 for ; Fri, 11 Jun 2010 23:04:12 +0200 (CEST) (envelope-from tijl@coosemans.org) From: Tijl Coosemans To: freebsd-current@freebsd.org Date: Fri, 11 Jun 2010 23:04:10 +0200 User-Agent: KMail/1.13.3 (FreeBSD/8.1-PRERELEASE; KDE/4.4.4; i386; ; ) References: <20100611162118.GR39829@acme.spoerlein.net> <867hm5tl6u.fsf@ds4.des.no> In-Reply-To: <867hm5tl6u.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201006112304.10952.tijl@coosemans.org> Subject: Re: Cleanup for cryptographic algorithms vs. compiler optimizations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 21:04:15 -0000 On Friday 11 June 2010 21:37:29 Dag-Erling Sm=C3=B8rgrav wrote: > Ulrich Sp=C3=B6rlein writes: >> optimizing compilers have a tendency to remove assignments that have >> no side effects. The code in sys/crypto/sha2/sha2.c is doing a lot >> of zeroing variables, which is however optimized away. [...] Is >> there a canonical way to zero those variables and should we use them >> (memset perhaps? what are the performance implications?) >=20 > If you stick these variables in a struct, you can memset the struct > to zero them; if there are many of them, it may be faster than > zeroing them individually. >=20 > Alternatively, you can use something like this: >=20 > #define FORCE_ASSIGN(type, var, value) \ > *(volatile type *)&(var) =3D (value) memset can be optimised away as well. The only way is to declare those variables volatile. None of the assignments below are removed for instance: volatile int a =3D 0; a =3D 1; a =3D 2;