Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Rainer Weikusat Newsgroups: comp.unix.programmer,comp.lang.c Subject: Re: Odd compiler behaviour? Date: Tue, 01 Mar 2016 19:26:11 +0000 Lines: 30 Message-ID: <871t7um23w.fsf@doppelsaurus.mobileactivedefense.com> References: <20160301061135.783@kylheku.com> <87h9gqb0lj.fsf@mantic.terraraq.uk> <878u22aua9.fsf@mantic.terraraq.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: individual.net BLFsmZR/vfRsz+NLD+hNXgkYkqJIWZ+N7rTkzSeMW5UIoXJBo= Cancel-Lock: sha1:oDO/HpwEhHNmN8XYCkIBrxW1j+M= sha1:PWjorFAWLok+qBHojz0QB8vU/2A= User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) Xref: csiph.com comp.unix.programmer:7978 comp.lang.c:82889 Richard Kettlewell writes: > Barry Margolin writes: >> Richard Kettlewell wrote: >>> This isn’t wrong but it does suggest that performance is more >>> important than programs having a single meaning, something that’s >>> cause a great deal of trouble over the years and continues to do so. >> >> C has always straddled the fence of being a "glorified assembly >> language" and being a high-level language. The first sense stresses >> that simple language elements should map directly into the corresponding >> CPU operations. That's why there's no array bounds checking, for >> instance. And sometimes this leads to non-portable code. > > This is a myth, at least since C89. Simple language elements do not map > directly onto the corresponding CPU operations. Out of bounds access to > arrays is good example. > > Given ‘static int a[10]’, a C expression such as a[n] doesn’t map to: > > add n*sizeof(int) to a and load > > ...which is a very simple operation on many CPUs, indeed a single > instruction in some common cases. Rather it maps to: > > if 0<=n<10 > add n*sizeof(int) to a and load > else There's certainly nothing in the C standard which requires a bounds check and conditionally not executing some code.