Afternoon everyone.

I have a quick question about standard C. Generally speaking, in my
experience, whenever one accesses an array there is never any bounds
checking done (either statically during compilation or dynamically
during runtime.) However, I was wondering if whether there is anything
defined in the standard about this.

The reason for this is I have some code conforming to ANSI C99 and
wish to write to both arrays and a block of memory allocated by malloc
and was wondering if I can say that there will never be any runtime
checking done to ensure that the location I am writing to exists.

Cheers,
Nick

polas said:

> Afternoon everyone.
>
> I have a quick question about standard C. Generally speaking, in my
> experience, whenever one accesses an array there is never any bounds
> checking done (either statically during compilation or dynamically
> during runtime.) However, I was wondering if whether there is anything
> defined in the standard about this.
>
> The reason for this is I have some code conforming to ANSI C99 and
> wish to write to both arrays and a block of memory allocated by malloc
> and was wondering if I can say that there will never be any runtime
> checking done to ensure that the location I am writing to exists.

A bounds violation invokes undefined behaviour; the Standard has nothing to
say about what will happen when a bounds violation occurs. Therefore, an
implementation can respond to a bounds violation in any way it likes - it
can ignore it, crash, report it, whatever. And, as long as bounds checking
doesn't break a strictly conforming program, the "as if" rule cuts in -
implementations can do whatever they like in the background as long as the
computational result of a strictly conforming program is not changed by
their behaviour.

In other words, the Standard neither forbids nor requires bounds checking.
A conforming implementation could certainly do bounds checking. Many do
not, because of the overhead it imposes on every program. Correct programs
don't need bounds checking. On the other hand, bounds checking can be very
useful during development. For this reason, an implementation that has
optional bounds checking (on during dev and test, off for the production
code) will score highly with its customers, on that issue at least.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

polas <nick@force.com> wrote:
> Afternoon everyone.

> I have a quick question about standard C. Generally speaking, in my
> experience, whenever one accesses an array there is never any bounds
> checking done (either statically during compilation or dynamically
> during runtime.) However, I was wondering if whether there is anything
> defined in the standard about this.

> The reason for this is I have some code conforming to ANSI C99 and
> wish to write to both arrays and a block of memory allocated by malloc
> and was wondering if I can say that there will never be any runtime
> checking done to ensure that the location I am writing to exists.

If a compiler supports this sort of checking, it's probably disabled by
default. I only know of one compiler*, actually, which supports this--TinyCC.
With TinyCC you have to enable it, using the -b switch.

Otherwise, the behavior is undefined as mentioned elsethread, and is usually
also unspecified by the compiler, so anything can happen (as opposed to
TinyCC w/ -b, where it specifies what it does).

* That is, in the form typically distributed, and without patching.

polas wrote:

> Afternoon everyone.
>
> I have a quick question about standard C. Generally speaking, in my
> experience, whenever one accesses an array there is never any bounds
> checking done (either statically during compilation or dynamically
> during runtime.) However, I was wondering if whether there is anything
> defined in the standard about this.
>
> The reason for this is I have some code conforming to ANSI C99 and
> wish to write to both arrays and a block of memory allocated by malloc
> and was wondering if I can say that there will never be any runtime
> checking done to ensure that the location I am writing to exists.

Bounds checking is neither required nor disallowed by the Standard. As
far as specific implementations are concerned for gcc the
options '-fmudflap', '-fmudflapth' and '-fmudflapir' enable and
configure some amount of bounds checking. A separate
library, 'libmudflap' needs to be linked with your program. For MSVC
you can use the '/RTC' and '/GS' options.

In addition you can use third-party tools like Purify or Valgrind to
test for memory access errors.

<http://valgrind.org/>
<http://www-306.ibm.com/software/awdtools/purifyplus/>

"polas" <nick@force.com> wrote in message
news:ef2b1077-0cb8-4dfb-aa5d-92ba50e0f971@q77g2000hsh.googlegroups.com...
> Afternoon everyone.
>
> I have a quick question about standard C. Generally speaking, in my
> experience, whenever one accesses an array there is never any bounds
> checking done (either statically during compilation or dynamically
> during runtime.) However, I was wondering if whether there is anything
> defined in the standard about this.
>
> The reason for this is I have some code conforming to ANSI C99 and
> wish to write to both arrays and a block of memory allocated by malloc
> and was wondering if I can say that there will never be any runtime
> checking done to ensure that the location I am writing to exists.

You can't be sure, because the standard doesn't say either way. It is
allowable for an implementation to do it or not do it -- or flip a coin each
time a violation happens.

In practice, most implementations don't do it, particularly on "common"
systems that most of us code for, because there is no direct hardware
support and thus it would slow things down. Some compilers have an option
that enables it, which is ful for debugging. Certain systems, e.g. the
AS/400, always do bounds checking since it's provided by the hardware.

However, the real answer is that you should never _rely_ on bounds checking
either being present or not present. Fix your code and it won't matter.

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking


--
Posted via a free Usenet account from http://www.teranews.com

In article <47a94b2d$0$26024$88260bb3@free.teranews.com>,
Stephen Sprunk <stephen@sprunk.org> wrote:
....
>However, the real answer is that you should never _rely_ on bounds checking
>either being present or not present. Fix your code and it won't matter.

In much the same way as you should never wear seat belts.

Drive perfectly safely and it won't matter.

On 6 Feb, 13:04, gaze...@xmission.xmission.com (Kenny McCormack)
wrote:
> In article <47a94b2d$0$26024$88260...@free.teranews.com>,Step hen Sprunk <step...@sprunk.org> wrote:
>
> ...
>
> >However, the real answer is that you should never _rely_ on bounds checking
> >either being present or not present. Fix your code and it won't matter.
>
> In much the same way as you should never wear seat belts.
>
> Drive perfectly safely and it won't matter.

Thanks for all the replies and - that clears it up for me. The
actual reason I was asking was with respect to efficiency, as
mentioned previously, bounds checking can be expensive and languages
which always do it have this overhead.

Nick

polas <n...@force.com> wrote:
> gaze...@xmission.xmission.com (Kenny McCormack) wrote:
> > Stephen Sprunk <step...@sprunk.org> wrote:
> > > However, the real answer is that you should never
> > > _rely_ on bounds checking either being present or
> > > not present. Fix your code and it won't matter.
> >
> > In much the same way as you should never wear seat
> > belts.

No, in the same way as you should never _rely_ on
seatbelts. Try reading what people say, as opposed to
what you think they say.

> > Drive perfectly safely and it won't matter.

Driving safely is always good advice, irrespective of
whether a there are seat belts. Note that many busses
do not have seatbelts. That doesn't mean or suggest
that drivers can afford to be reckless.

> Thanks for all the replies and - that clears it
> up for me. The actual reason I was asking was with
> respect to efficiency, as mentioned previously, bounds
> checking can be expensive and languages which always
> do it have this overhead.

Yes, but not as much as you might think.

Note that C's pointer freedom comes at a cost in that
certain optimisations can't be performed.

--
Peter

"Kenny McCormack" <gazelle@xmission.xmission.com> wrote in message
news:focb98$flp$2@news.xmission.com...
> In article <47a94b2d$0$26024$88260bb3@free.teranews.com>,
> Stephen Sprunk <stephen@sprunk.org> wrote:
>>However, the real answer is that you should never _rely_ on bounds
>>checking
>>either being present or not present. Fix your code and it won't matter.
>
> In much the same way as you should never wear seat belts.

Flawed analogy. Putting on a seat belt is an active thing, much like
writing my own code to verify I don't do something unexpected (like an
out-of-bounds access). Passively relying on a car's airbags to protect me
is like relying on an implementation to do my bounds checking for me.

> Drive perfectly safely and it won't matter.

I don't wear my car's seat belt because of my driving; I wear it because of
others'. And, while I dropped my motorcycle a few times when I first got
it, the only time I've ever needed the helmet I wear is when another driver
made an illegal turn and hit me, resulting in me flying over his hood and
landing head-first on the pavement. I drive defensively, and I code
defensively. I only stray outside what the C standard guarantees me in
modules specifically marked as unportable, and I strive to keep them as
small as feasible.

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking