Return to the
comp.compilers page.
Search the
comp.compilers archives again.
| Related articles |
|---|
| [5 earlier articles] |
| Re: another C-like language? was Compilers :) gah4@u.washington.edu (gah4) (2023-01-04) |
| Re: another C-like language? was Compilers :) marblypup@yahoo.co.uk (marb...@yahoo.co.uk) (2023-01-05) |
| Re: another C-like language? was Compilers :) gah4@u.washington.edu (gah4) (2023-01-05) |
| Re: another C-like language? was Compilers :) david.brown@hesbynett.no (David Brown) (2023-01-06) |
| Re: another C-like language? was Compilers :) marblypup@yahoo.co.uk (marb...@yahoo.co.uk) (2023-01-07) |
| Re: another C-like language? was Compilers :) david.brown@hesbynett.no (David Brown) (2023-01-08) |
| Re: another C-like language? was Compilers :) DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2023-01-09) |
| Re: C scopes, another C-like language? was Compilers :) david.brown@hesbynett.no (David Brown) (2023-01-09) |
| Re: another C-like language? was Compilers :) 864-117-4973@kylheku.com (Kaz Kylheku) (2023-01-09) |
| Re: another C-like language? was Compilers :) Keith.S.Thompson+u@gmail.com (Keith Thompson) (2023-01-09) |
| Re: another C-like language? was Compilers :) david.brown@hesbynett.no (David Brown) (2023-01-10) |
| Re: another C-like language? was Compilers :) gah4@u.washington.edu (gah4) (2023-01-10) |
| Re: another C-like language? was Compilers :) tkoenig@netcologne.de (Thomas Koenig) (2023-01-11) |
| [9 later articles] |
| From: | Hans-Peter Diettrich <DrDiettrich1@netscape.net> |
| Newsgroups: | comp.compilers |
| Date: | Mon, 9 Jan 2023 04:48:37 +0100 |
| Organization: | Compilers Central |
| References: | 23-01-001 23-01-002 23-01-003 23-01-008 23-01-020 23-01-024 |
| Injection-Info: | gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="22819"; mail-complaints-to="abuse@iecc.com" |
| Keywords: | C, optimize |
| Posted-Date: | 09 Jan 2023 11:39:31 EST |
| In-Reply-To: | 23-01-024 |
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*.
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.
DoDi
Return to the
comp.compilers page.
Search the
comp.compilers archives again.