Path: csiph.com!aioe.org!.POSTED!not-for-mail From: Rod Pemberton Newsgroups: comp.lang.forth Subject: Re: Average swaps per word? Date: Tue, 15 Nov 2016 17:49:06 -0500 Organization: Aioe.org NNTP Server Lines: 55 Message-ID: <20161115174906.792ede7c@_> References: <5352ea02-4942-40bf-8c92-e5012aae1807@googlegroups.com> <2016Nov12.132348@mips.complang.tuwien.ac.at> <2016Nov13.155518@mips.complang.tuwien.ac.at> <871syff9mv.fsf@nightsong.com> <2016Nov14.184256@mips.complang.tuwien.ac.at> NNTP-Posting-Host: n4wpt9zq8xR26Ttf9mo2BA.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org X-Notice: Filtered by postfilter v. 0.8.2 X-Newsreader: Claws Mail 3.13.1 (GTK+ 2.24.13; x86_64-unknown-linux-gnu) Xref: csiph.com comp.lang.forth:52662 On Tue, 15 Nov 2016 03:55:45 -0600 Andrew Haley wrote: > Anton Ertl wrote: > > > Looking at the C11 standard for memset_s, I did not see anything > > that would keep a sufficiently adverserial compiler writer from > > optimizing it away. It says: > > > > |Unlike memset, any call to the memset_s function shall be evaluated > > |strictly according to the rules of the abstract machine as > > described |in (5.1.2.3). That is, any call to the memset_s function > > shall assume |that the memory indicated by s and n may be > > accessible in the future |and thus must contain the values > > indicated by c. > > > > Now, everything else (including memset()) in the standard also is > > evaluated according to the rules of the abstract machine, and the > > "optimization" comes in afterwards, applies the as-if rule, and > > poof, memset() is gone, and so is memset_s(). From what I read, > > "volatile" is not specified very clearly, so it probably has this > > problem and more. > > That's true, but I don't believe that it's possible to do any better > with a language specification based on an abstract machine. C11 still > says that > > What constitutes an access to an object that has volatile-qualified > type is implementation-defined. > > so it's possible for an "adversarial compiler" to optimize away > volatile too. I don't think any do, though, which is perhaps the > point. > Optimizing away volatile would defeat the purpose of having volatile implemented by the language, wouldn't it? I would think that phrase more likely means that volatile can be entirely optional, or that the precise implementation details of volatile is specific to each platform. I'd guess that most C compilers are likely to choose the latter, implementing volatile, since most also support casting integers into pointers, which is undefined or implementation-defined behavior too. But, you could have a pedantic C compiler which doesn't support volatile at all due to it being non-portable. Well, that's what that means to me, anyway. If it's seriously an issue for Anton, there is always comp.std.c to which he post, but a quick scan doesn't show any posts from the C experts who contributed to and wrote the C specifications who posted there years ago. Rod Pemberton