From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gentoo-user+bounces-180786-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by finch.gentoo.org (Postfix) with ESMTPS id 20A461396D9
	for <garchives@archives.gentoo.org>; Wed, 15 Nov 2017 08:54:10 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
	by pigeon.gentoo.org (Postfix) with SMTP id 13156E0C7C;
	Wed, 15 Nov 2017 08:54:03 +0000 (UTC)
Received: from blaine.gmane.org (unknown [195.159.176.226])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by pigeon.gentoo.org (Postfix) with ESMTPS id 9EFC7E0C5A
	for <gentoo-user@lists.gentoo.org>; Wed, 15 Nov 2017 08:54:02 +0000 (UTC)
Received: from list by blaine.gmane.org with local (Exim 4.84_2)
	(envelope-from <lnx-gentoo-user@m.gmane.org>)
	id 1eEtSA-000640-4H
	for gentoo-user@lists.gentoo.org; Wed, 15 Nov 2017 09:53:50 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: gentoo-user@lists.gentoo.org
From: Nikos Chantziaras <realnc@gmail.com>
Subject: [gentoo-user] Re: memset_s
Date: Wed, 15 Nov 2017 10:54:02 +0200
Message-ID: <ougvan$1va$1@blaine.gmane.org>
References: <CAKpSnpJ=vs36FjA6qRpFCYTZKreFdqe=bMqa9+kbZCL0FL7fDQ@mail.gmail.com>
 <26501197.ioODuGg76y@thetick>
 <CAKpSnpJ-FrOBttWNbOqiDxNLnQ5kTsHAbTNgZvRUSgL4hUxb=w@mail.gmail.com>
 <CAAD4mYj8foKjO7LShWcdttm7NSPEfo8pnj1TavVjxyAZSSRmmA@mail.gmail.com>
 <CAKpSnp+jw=Xdq7V4ZZDzdFb7GMTb+ES7Mxq2PwQH-EcVqBHhdA@mail.gmail.com>
 <CAKpSnpJ0NHBnzj6ggEkx4TG36oNFBk7k=UoKxHC+5Wmw7029Kg@mail.gmail.com>
Precedence: bulk
List-Post: <mailto:gentoo-user@lists.gentoo.org>
List-Help: <mailto:gentoo-user+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-user+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-user+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-user.gentoo.org>
X-BeenThere: gentoo-user@lists.gentoo.org
Reply-to: gentoo-user@lists.gentoo.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@blaine.gmane.org
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.4.0
In-Reply-To: <CAKpSnpJ0NHBnzj6ggEkx4TG36oNFBk7k=UoKxHC+5Wmw7029Kg@mail.gmail.com>
Content-Language: en-US
X-Archives-Salt: 3a76eeff-a7e4-44d3-b928-d1147b209f86
X-Archives-Hash: 9ab1f879953056c9ae97ea6a66b4fb68

On 14/11/17 19:36, Jorge Almeida wrote:
> On Fri, Nov 10, 2017 at 12:09 PM, Jorge Almeida <jjalmeida@gmail.com> wrote:
> 
>> http://www.daemonology.net/blog/2014-09-04-how-to-zero-a-buffer.html
>>
>>
>>>> Of course, what would really solve the optimize-into-oblivion problem
>>>> is a pragma that when invoked on a particular block of code (maybe
>>>> only a function definition) would tell the compiler to do what the
>>>> programmer says rather than viewing a function as a kind of black box.
>>>>
>>>
> 
> It seems a solution exists with gcc:
> 
> https://stackoverflow.com/questions/2219829/how-to-prevent-gcc-optimizing-some-statements-in-c
> 
> The last reply:
> 
> void __attribute__((optimize("O0"))) foo(unsigned char data) {
>      // unmodifiable compiler code
> }
> 
> Any comments, anyone?
Unless you look at the assembly output, you can't be sure. Some 
optimization is done even at -O0.

I'd stick to using explicit_bzero() which is safe regardless of compiler 
vendor *and* version.