Re: compiler bugs

Barry Kelly <>
Sun, 10 May 2009 01:28:11 +0100

          From comp.compilers

Related articles
[21 earlier articles]
Re: compiler bugs (2009-05-05)
Re: compiler bugs (glen herrmannsfeldt) (2009-05-05)
Re: compiler bugs (glen herrmannsfeldt) (2009-05-05)
Re: compiler bugs (Christopher Glaeser) (2009-05-06)
Re: compiler bugs (2009-05-06)
Re: compiler bugs (Chris F Clark) (2009-05-07)
Re: compiler bugs (Barry Kelly) (2009-05-10)
Re: compiler bugs (2009-05-10)
| List of all articles for this month |

From: Barry Kelly <>
Newsgroups: comp.compilers
Date: Sun, 10 May 2009 01:28:11 +0100
Organization: Compilers Central
References: 09-04-072 09-04-086 09-05-010 09-05-022 09-05-028 09-05-038 09-05-039 09-05-050
Keywords: errors, debug
Posted-Date: 12 May 2009 04:55:43 EDT

Chris F Clark wrote:

> > Not if the unoptimizing compiler initializes all variables to some
> > known value.
> So, if you have an algorithm that needs a trick like the above to meet
> its performance promises, then the unoptimizing compiler breaks your
> algorithm (and we don't have a well-known optimization technique that
> fixes that breakage).

I'm partial to the C# approach myself. The safe subset of the language
is capable, and for the particular case in question, all locals are
zeroed out by the compiler by default, even though the language requires
definite assignment before use. (So the optimizing JIT won't pay
performance-wise here, as it can eliminate the redundant

However, if tricks are required to meet performance goals, there is the
escape valve of unsafe code, wherein one can fall back to C-level

> Yes, one can design a language that is safe, but every attempt to do
> so, has restricted the language such that certain short-cuts that may
> be generally unsafe, but can be safe in certain instances, are
> prohibited. The question then is whether those short-cuts are
> required in ones application.

I think the dichotomy apparently in question, to be safe or not to be
safe, is false. If the safe subset is strongly encouraged (and in the
case of C# and .NET etc., often mandated for business reasons when using
e.g. third-party application servers), yet an "out" is possible, is this
not all that is needed?

-- Barry


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.