Path: csiph.com!1.us.feeder.erje.net!feeder.erje.net!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: David Brown Newsgroups: comp.compilers Subject: Re: C scopes, another C-like language? was Compilers :) Date: Mon, 9 Jan 2023 18:12:22 +0100 Organization: A noiseless patient Spider Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <23-01-028@comp.compilers> References: <23-01-001@comp.compilers> <23-01-002@comp.compilers> <23-01-003@comp.compilers> <23-01-008@comp.compilers> <23-01-020@comp.compilers> <23-01-024@comp.compilers> <23-01-025@comp.compilers> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="31793"; mail-complaints-to="abuse@iecc.com" Keywords: C, history Posted-Date: 09 Jan 2023 21:33:48 EST X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com In-Reply-To: <23-01-025@comp.compilers> Content-Language: en-GB Xref: csiph.com comp.compilers:3296 On 09/01/2023 04:48, Hans-Peter Diettrich wrote: > On 1/8/23 8:21 PM, David Brown wrote: > >> In other words, it can combine all the variables declared in nested >> scope and act as though they were all defined at the start of the >> function. > > AFAIR nested scopes were introduced just to allow for space saving > memory overlays. Regardless of whether a compiler really takes that > optimization *option*. I don't know the history as to /why/ block scope variables were introduced in C - that was all before my time. But they certainly allow you to write better structure in your code (in my opinion, anyway - I am aware that some people think "declare all variables at the start of the function before any code" gives better code). IMHO, local variables should have as small a scope as practically possible. So even if I have to use C90 (which I dislike - C99 was a big improvement), if I have a variable that is only needed inside a loop or a conditional, I'll declare it there. Compilers have always been free to use lifetime analysis to merge or overlap variables, regardless of how and where they are declared inside a function. There have never been any requirements from the language forcing compilers to have separate "stack slots" for variables that are declared at the start of a function or within the same block. Of course, compilers of old were not as sophisticated as modern compilers, and debuggers of old were also more limited, so it was quite common to have fixed and dedicated stack slots for each variable declared at the start of the function. But it was never /required/ for correct implementation of the language. > Of course problems can arise from malware assuming memory contents as > left over from a previous block, as it's not required that the compiler > initializes all local variables on block entry. > You are required to initialise or assign to all local variables that you read. Failing to do so is undefined behaviour (or in some circumstances, unspecified behaviour). And it doesn't matter whether you initialise your local variable at the start of a block, or assign to it later when you use it - the compiler is under no obligation to make any initialisation at the start of the block, regardless of what you write. It only has to make sure you get the same results in the end as you would have had if it had followed your source code directly. If malware can execute its code inside your functions (from code injections, buffer overflows, etc.), then all sorts of things can go wrong. Initialising local variables at the start of a block can reduce the risks and consequences a bit, but it will not save you.