Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: otRe: Difference between these pointer syntaxes Date: Sat, 27 Aug 2016 15:57:07 -0700 Organization: None to speak of Lines: 38 Message-ID: References: <86fe4ec0-6dcd-4aa0-8a21-f8e57038c3bb@googlegroups.com> <8ccb11cd-a386-48d9-b970-22eb044f84ca@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="8708"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1//CosdODtXTEOcwn8Py7qH" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:+D1G9jgV0Jqc2Dj4imYmSeUepTY= sha1:Zcmk1/opIbOPiX3MHs0K0x4cgeI= Xref: csiph.com comp.lang.c:92826 BartC writes: > On 27/08/2016 21:47, jameskuyper@verizon.net wrote: >> On Saturday, August 27, 2016 at 2:31:42 PM UTC-4, Bart wrote: >>> On 27/08/2016 19:52, Keith Thompson wrote: >>>> Imagine an implementation that marks uninitialized memory and traps >>>> if you attempt to read it. >>> >>> OK, I'm trying hard to imagine such a system. But all I see is a >>> responsibility of the OS, or any start-up code, to clear all RAM before > > > The values of those variables are indeterminate at the start of each > > pass through their respective loops. An implementation is allowed, > > but not required, to allocate them in the same memory location during > > each pass. If a previous pass through the loop caused the variable to > > acquire a trap representation, > > I had in mind Keith's scenario which might have resulted from a power-up > condition and therefore easily fixed by initialising all memory > including that to be used for auto and heap storage. The point of the scenario is that uninitialized memory would be marked somehow so that attempts to read values from it would be detected. Detecting attempts to use uninitialized values is a good thing, and bypassing such a mechanism by implicitly initializing all memory would makes it more difficult to detect bad code. I've seen systems that, in some modes, initialize otherwise uninitialized memory to a repeating pattern of 0xE5, which doens't reliably trap accesses but at least can make them easier to diagnose. [...] -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"