Bounds checking and safety in C

[Richard]

Richard said:


"Certified", I wouldn't know about. But the definition of "strictly
conforming" is not a secret:

"A strictly conforming program shall use only those features of
the language and library specified in this Standard. It shall
not produce output dependent on any unspecified, undefined, or
implementation-defined behavior, and shall not exceed any minimum
implementation limit."

So theory then and almost impossible to achieve in real life since it's
impossible to, IMO, to predetermine that your program will react
properly under all variations of potential user input.

 

[Kenny McCormack]

This whole rubbish is just to destroy any technical
discussion about the issues I raised, using this
pseudo technical language legalese.

Yup. Exactly so.
This is called "Thread hijacking".

 

[Richard Tobin]

This whole rubbish is just to destroy any technical
discussion about the issues I raised, using this
pseudo technical language legalese.

You could improve the situation by not responding to such articles.
Just stick to the technical stuff.

-- Richard

 

[Richard]

No, it isn't. If it _were_ possible for a strictly conforming program to
violate object bounds, a bounds checking implementation would be
legal.

So "if conforming program violates" then bounds checking is legal.

Since it is _not_ possible, a bounds checking implementation is legal
and, get this, on occasion very _practical_ to discover where your

Since "its not possible for conforming program to violate", checking is
legal.

program is not strictly conforming in a bounds-violating way.

I do have my thick head on. I don't understand anything of the past few
points about "conforming" programs. It sounds like a load of mumbo jumbo.

Richard

--

 

[Serve Lau]

Bounds checking is nice and all, but it certainly is no panacea.
It may even not be *that* useful IMO. Here is why:

1. No bounds checking. You read or write data outside bounds. It
generates an exception.

NO, in most cases writing beyond a variable's specified length doesn't
produce any exception.

Consider this program:
int fn(int *p,int c)
{
return p[c];
}

int main(void)
{
int tab[3];

int s = fn(tab,3);
}

Please tell me a compiler system where this program generates an
exception.

Dont know if this is what you mean but VisualStudio2005 says:
"runtime check failure. stack around the variable tab was corrupted"

make sure stuff is not optimized away though

 

[Flash Gordon]

Ian Collins wrote, On 30/07/07 02:19:

Well I still support a couple of embedded projects and I can't remember
the last time I did any debugging on the targets. Everything is
developed and unit tested on the host, even the acceptance test suite
can run against both the target and the host simulation.

I agree with Ian that you can test well written embedded SW in a hosted
environment. I'm out of the embedded market now, but when I was in it I
successfully debugged code that was targeting an embedded system by
building it with appropriate replacement IO code on a workstation.

I've also used some *very* sophisticated HW emulators/In-circuit
emulators which did not do bounds checking, but could check for
read-before-write and do all sorts of other things that I've not come
across for hosted implementations. Some of these systems provided
standard file IO to the embedded program.

But they are not required everywhere. On many embedded targets, there
simply would not be space for the extra code.

Even more important is what is the implementation going to do if it
detects an out-of-bounds access? I certainly don't want to have to
switch off my car when doing 70MPH in the fast lane of the M25!

 

[Flash Gordon]

jacob navia wrote, On 30/07/07 10:40:
As another poster pointed out you meant bounds checking would be illegal.

Are you a lawyer?

It looks like.

tell me then, how can I know if a program is
"strictly conforming" then?

That is worst than the halting problem!

No, it is the same as the halting problem, but that is completely
irrelevant.

This whole rubbish is just to destroy any technical
discussion about the issues I raised, using this
pseudo technical language legalese.

No, Richard was making a very valid technical point. Namely that if you
change lcc-win32 to do full bounds checking it would not affect its
conformance to the C standard. So if you want bounds-checking C just
change your compiler to do it and it might even encourage some people
here to use it for testing their code!

As I understand it part of the reason why going out-of-bounds invokes
undefined behaviour is to *allow* bounds-checking implementations to be
legal!

 

[Richard Heathfield]

jacob navia said:

tell me then, how can I know if a program is
"strictly conforming" then?

That is worst than the halting problem!

A pointless objection to a non-issue. Nobody is arguing that a compiler
must know whether its input is a strictly conforming C program. That
you should think so is just bizarre.

This whole rubbish is just to destroy any technical
discussion about the issues I raised, using this
pseudo technical language legalese.

Wrong. It was actually to point out that you *can* implement a
bounds-checker if you want - the Standard doesn't stop you. That you
should think otherwise is even more bizarre.

 

[Richard Heathfield]

Richard said:

I do have my thick head on. I don't understand anything of the past
few points about "conforming" programs. It sounds like a load of mumbo
jumbo.

If further proof were needed that there is no point engaging with Mr
Riley, this would seem to be it. I apologise to the group for treating
him seriously; it is now evident to me that this was a waste of time.

 

[Richard Heathfield]

Flash Gordon said:

Even more important is what is the implementation going to do if it
detects an out-of-bounds access?

Well, presumably that feature would only be used during debugging.

I certainly don't want to have to
switch off my car when doing 70MPH in the fast lane of the M25!

You won't have to - the M25 doesn't /have/ a fast lane.

 

[Richard]

Richard said:



If further proof were needed that there is no point engaging with Mr
Riley, this would seem to be it. I apologise to the group for treating
him seriously; it is now evident to me that this was a waste of time.

I make no apologies for being confused by your constant thread
hijacking and ability to turn relatively simple concepts into high brow
mumbo jumbo. Your self regard eclipses any contributions you might make
IMO.

 

[jacob navia]

Well I still support a couple of embedded projects and I can't remember
the last time I did any debugging on the targets. Everything is
developed and unit tested on the host, even the acceptance test suite
can run against both the target and the host simulation.

In most cases this is a recipe for disaster.
Only the most perfect emulators can REALLY
reproduce 100% of the features of the target, either
because it is too slow/too fast for the same real
time conditions, either because the simulated input stream
doesn't correspond with the actual input stream 100%,
and a thousand of other reasons.

The emulator is never the REAL THING, it is a an emulator!


Of course all this depends on the specific machine being used
For some applications an emulator can be OK, probably.

It's no where near that bad. Yes there is a performance penalty, but
this can be mitigated by only applying the full set of checks to
selected parts of the application.

OK. Then you would agree with me that this feature

#pragma STDC_BOUNDS_CHECK(ON)

would be much better since it wouldn't be constrained
to just dbx...

But they are not required everywhere. On many embedded targets, there
simply would not be space for the extra code.

Maybe, maybe not, it depends. In any case nobody is advocating making
it mandatory.

The real problem behind this is the difficulty of the standard library
since if you store the meta data with the object, the object layout
changes slightly and all library routines not compiled with bounds
checking will not work.

That is why a standard procedure would much better.

It would be possible to build compatible libraries.

 

[jacob navia]

So theory then and almost impossible to achieve in real life since it's
impossible to, IMO, to predetermine that your program will react
properly under all variations of potential user input.

Exactly. That is why all that concept is just empty legalese that
doesn't bring anything to the actual discussion!

 

[Richard Tobin]

for me it is all wrong
the % of slowness should be 0%

Yes, but unlike you the authors of the paper actually did some research.

-- Richard

 

[¬a\\/b]

for me it is all wrong
the % of slowness should be 0%
because only the function free() when free pointer see if two bounds
have new values . end.

a c program for me can read what it likes memory too not own;
the problem it is not have to write in it
so above "solution" could be ok for mallocced memory
for stack memory or other i don't know

 

[William Hughes]

tell me then, how can I know if a program is
"strictly conforming" then?

In general you cannot. However, examples of strictly
conforming programs can be given and some properties
of stictly conforming programs can be listed.


One property of all stictly conforming programs
is that they do not have bounds violations.

This (theoretical) property is enough to
conclude that a C implementation may
include a bounds checker without the
C standard.

So we have three questions:

i: Q: Is a C implementation allowed to have bounds checking
A: Yes (follows from considerations of stictly conforming
programs)

ii: Q: Is it practical for a C implementation to have bounds checking
A: Yes, examples exist.

iii: Q: Should changes be made to C so that implementing a bounds
checker is easier.
A: Disputed. However, your claim that a lot of people answer "no"
with the justification "bounds checking carries too large of
a performance penalty" is dubious at best.

- William Hughes

 

[jacob navia]

In general you cannot. However, examples of strictly
conforming programs can be given and some properties
of stictly conforming programs can be listed.


One property of all stictly conforming programs
is that they do not have bounds violations.

This (theoretical) property is enough to
conclude that a C implementation may
include a bounds checker without the
C standard.

So we have three questions:

i: Q: Is a C implementation allowed to have bounds checking
A: Yes (follows from considerations of stictly conforming
programs)

ii: Q: Is it practical for a C implementation to have bounds checking
A: Yes, examples exist.

iii: Q: Should changes be made to C so that implementing a bounds
checker is easier.
A: Disputed. However, your claim that a lot of people answer "no"
with the justification "bounds checking carries too large of
a performance penalty" is dubious at best.

- William Hughes

That is the justification I hear most often.

The second is the "spirit of C". C is for macho programmers
that do not need bounds checking because they never make mistakes.

And there are others.

I wanted with my post address the first one. Those researchers
prove that a FAST implementation of bounds checking is
feasible even without language support.

I would say that with language support, the task would be much easier
AND much faster, so fast that it could be done at run time without
any crushing overhead.

jacob

 

[JT]

Those researchers
prove that a FAST implementation of bounds checking is
feasible even without language support.
Yes.

I would say that with language support, the task would be much easier
AND much faster, so fast that it could be done at run time without
any crushing overhead.

You "would" say?

What sample of code have you converted into
the new SuperSafeC dialect and then compared
the performance? etc. etc.

(By the way, you might also want to look
at other ways of making C safer.
For example, CCured is a dialect of C
developed at UC Berkeley that forces
the programmer to add suitable
annotation, but then guarantees type safety)

You need to do due diligence and research first.

 

[William Hughes]

Keith Thompson said: [...]

On the other hand, there are some presumably valid C constructs that
could break in the presence of bounds checking, such as the classic
"struct hack" and code that assumes two-dimensional arrays can be
accessed as one-dimensional arrays.

Do you have any examples of valid C constructs that are actually valid?

I don't think that's *quite* what you meant.

Both the struct hack and the 2d/1d hack are actually invalid C. And
before you start: the codification of the struct hack in C99 involved a
syntax change, so you can put /that/ Get Out Of Jail Free card back in
the pack!

I actually can't think of any realistic examples off the top of my
head. But there are plenty of programs that aren't strictly
conforming but that a conforming implementation must accept.

Indeed, but this just means that an executable must
be produced.

example, a program that prints the value of INT_MAX is not strictly
conforming.

What I have in mind in general is that a bounds-checking
implementation might make incorrect assumptions about when checks can
be removed or, more relevantly, when they can be proven during
compilation to fail.

Even if there is a conforming program that can be proven duing
compilation
have bounds violations, all this means is that the compiler
may have to produce an executable (A reasonable behaviour
would be to output a warning that there is a bounds violation
and let the dynamic bounds checking stuff deal with it).

With certain sets of assumptions, no strictly
conforming programs would be affected, but some correct programs that
depend on implementation-defined behavior could be.

It seems fairly clear to me that such examples are theoretically
possible. If you're still not convinced, I can try to come up with
something more concrete.

I am not convinced that an example of a conforming program that
could be shown at compile time to violate bounds exists.

- William Hughes

 

[jacob navia]

You "would" say?

What sample of code have you converted into
the new SuperSafeC dialect and then compared
the performance? etc. etc.

The most obvious example is the development of
length delimited strings.

strlen becomes just a memory read with those strings.
Much faster *and safer* than an UNBOUNDED memory scan!

Other functions like strcat that implicitly call
strlen are FASTER.

I have been promoting this change (without obsoleting
zero terminated strings of course for legacy code)
for several years. Maybe you are new here and did not see
my other posts.

(By the way, you might also want to look
at other ways of making C safer.
For example, CCured is a dialect of C
developed at UC Berkeley that forces
the programmer to add suitable
annotation, but then guarantees type safety)

The annotations chapter is a huge issue in itself.
But I can't say everything in one post please.

You need to do due diligence and research first.

Thanks for the advice but what makes you think I haven't done it?