Bounds checking

[polas]

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

 

[Richard Heathfield]

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.

 

[William Ahern]

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.

 

[santosh]

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/>

 

[Stephen Sprunk]

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 helpful 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

 

[Kenny McCormack]

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.

 

[polas]

...


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 help - 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

 

[Peter Nilsson]

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.

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 help - 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.

 

[Stephen Sprunk]

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