Bounds checking and safety in C

[jacob navia]

We hear very often in this discussion group that
bounds checking, or safety tests are too expensive
to be used in C.

Several researchers of UCSD have published an interesting
paper about this problem.

http://www.jilp.org/vol9/v9paper10.pdf

Specifically, they measured the overhead of a bounds
checking implementation compared to a normal one, and
found that in some cases the overhead can be reduced
to a mere 8.3% in some cases...

I quote from that paper

< quote >
To summarize, our meta-data layout coupled with meta-check instruction
reduce the average overhead of bounds checking to 21% slowdown which is
a significant reduction when compared to 81% incurred by current
software implementations when providing complete bounds checking.
< end quote>

This 21% slowdown is the overhead of checking EACH POINTER
access, and each (possible) dangling pointer dereference.

If we extrapolate to the alleged overhead of using some extra
arguments to strcpy to allow for safer functions (the "evil
empire" proposal) the overhead should be practically ZERO.

Somehow, we are not realizing that with the extreme power of the
CPUs now at our disposal, it is a very good idea to try to
minimize the time we stay behind the debugger when developing
software. A balance should be sought for improving the safety
of the language without overly compromising the speed of the
generated code.

I quote again from that paper:

< quote >
As high GHZ processors become prevalent, adding hardware support to
ensure the correctness and security of programs will be just as
important, for the average user, as further increases in processor
performance. The goal of our research is to focus on developing
compiler and hardware support for efficiently performing software checks
that can be left on all of the time, even in production code releases,
to provide a signicant increase in the correctness and security of
software.

< end quote >

The C language, as it is perceived by many people here, seems
frozen in the past without any desire to incorporate the changing
hardware/software relationship into the language itself.

When this issues are raised, the "argument" most often presented is
"Efficiency" or just "it is like that".

This has lead to the language being perceived as a backward and error
prone, only good for outdated software or "legacy" systems.

This pleases again the C++ people, that insist in seeing their language
as the "better C", and obviously, C++ is much better in some ways as
C, specially what string handling/common algorithms in the STL/ and
many other advances.

What strikes me is that this need not be, since C could with minimal
improvements be a much safer and general purpose language than it is
now.

Discussion about this possibility is nearly impossible, since a widely
read forum about C (besides this newsgroup) is non existing.

Hence this message.

To summarize:

o Bounds checking and safer, language supported constructs are NOT
impossible because too much overhead
o Constructs like a better run time library could be implemented in a
much safer manner if we would redesign the library from scratch,
without any effective run time cost.
jacob

P.S. If you think this article is off topic, please just ignore it.
I am tired of this stupid polemics.

[Richard Heathfield]

jacob navia said:

We hear very often in this discussion group that
bounds checking, or safety tests are too expensive
to be used in C.

The C Standard neither requires nor forbids bounds checking. A strictly
conforming program will violate no bounds, and so presumably will not
be able to detect the existence of a bounds checker. Therefore, it's
perfectly acceptable for an implementation to incorporate this feature.
And indeed some do, although typically only in debug mode, for what I
hope are obvious reasons. This is entirely a QoI issue.

<snip>

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

[Richard]

Richard Heathfield <rj*@see.sig.invalidwrites:

jacob navia said:

>We hear very often in this discussion group that
bounds checking, or safety tests are too expensive
to be used in C.

The C Standard neither requires nor forbids bounds checking. A strictly
conforming program will violate no bounds, and so presumably will not

A conforming program can still have bugs. Or?

be able to detect the existence of a bounds checker. Therefore, it's
perfectly acceptable for an implementation to incorporate this feature.
And indeed some do, although typically only in debug mode, for what I
hope are obvious reasons. This is entirely a QoI issue.

<snip>

--

[Richard Heathfield]

Richard said:

Richard Heathfield <rj*@see.sig.invalidwrites:

>jacob navia said:

>>We hear very often in this discussion group that
bounds checking, or safety tests are too expensive
to be used in C.

The C Standard neither requires nor forbids bounds checking. A
strictly conforming program will violate no bounds, and so presumably
will not

A conforming program can still have bugs. Or?

I actually said "strictly conforming program". A strictly conforming
program does not contain any instances of undefined behaviour. (If it
did, it would not be strictly conforming.) Therefore, it cannot violate
any bounds.

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

[Ian Collins]

jacob navia wrote:

>
Somehow, we are not realizing that with the extreme power of the
CPUs now at our disposal, it is a very good idea to try to
minimize the time we stay behind the debugger when developing
software. A balance should be sought for improving the safety
of the language without overly compromising the speed of the
generated code.

As Richard H. pointed out, this is a QoI issue. For may years I have
been using a development environment that supports run time bounds and
leak checking and I probably wouldn't use one that didn't.

There are alternatives to C if you want performance and better memory
safety.

--
Ian Collins.

[Richard]

Richard Heathfield <rj*@see.sig.invalidwrites:

Richard said:

>Richard Heathfield <rj*@see.sig.invalidwrites:

>>jacob navia said:

We hear very often in this discussion group that
bounds checking, or safety tests are too expensive
to be used in C.

The C Standard neither requires nor forbids bounds checking. A
strictly conforming program will violate no bounds, and so presumably
will not

A conforming program can still have bugs. Or?

I actually said "strictly conforming program". A strictly conforming
program does not contain any instances of undefined behaviour. (If it
did, it would not be strictly conforming.) Therefore, it cannot violate
any bounds.

How does a program get so certified?

[Guillaume]

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. (All implementations where it doesn't always
generate an exception, or worse, where it can lead to code execution, is
brain-dead IMO, but that's another story. Thus, it's not a problem of
bounds checking or not.)

2. Bounds checking. You read or write data outside bounds. It generates
an 'out of bounds' exception.

Not that much different. In both cases, you need to handle the
exception. How you must handle it in its particular context really *is*
the main issue here, and the main difficulty.

"Manual" bounds checking here and there in your code can be useful -
mostly because you know why you want to check that at this point and how
you're gonna handle the occasional out-of-bounds cases.

But systematic bounds checking? I don't believe in that.
You opinion may vary. But I'm waiting for strong arguments.

[jacob navia]

Bjoern Vian wrote:

Richard Heathfield schrieb:

>I actually said "strictly conforming program". A strictly conforming
program does not contain any instances of undefined behaviour. (If it
did, it would not be strictly conforming.) Therefore, it cannot
violate any bounds.

Ok, but that is completely irrelevant for programming practice;
it's pure theory.

It is not even theory

What he is saying is:

"A strictly conforming program does not contain any instances of
undefined behavior."

What this abstraction bring to us in useful consequences is
zero since nowhere it is specified how to prove/disprove
that program "a" is strictly conforming or not!

But let's close this parentheses. Heathfield posted that
message 9 minutes after I posted mine, with some "bla bla"
without substance. He did not read the article of those
researchers, and he addresses NONE of the issues I raised.

Please let's return to those issues!

jacob

[Richard Heathfield]

Richard said:

Richard Heathfield <rj*@see.sig.invalidwrites:

<snip>

>A strictly conforming
program does not contain any instances of undefined behaviour. (If it
did, it would not be strictly conforming.) Therefore, it cannot
violate any bounds.

How does a program get so certified?

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

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

[Keith Thompson]

Bjoern Vian <Bj*********@gmx.liwrites:

Richard Heathfield schrieb:

>I actually said "strictly conforming program". A strictly conforming
program does not contain any instances of undefined behaviour. (If
it did, it would not be strictly conforming.) Therefore, it cannot
violate any bounds.

Ok, but that is completely irrelevant for programming practice;
it's pure theory.

I agree that the category of "strictly conforming programs" is too
narrow to be particularly useful to programmers. (It's useful
primarily in defining conforming implementations, I think.)

However, bounds checking affects behavior only for programs that
already exhibit undefined behavior. For non-buggy programs, bounds
checking should have no effect other than performance. For buggy
programs, bounds checking can reveal the bugs (that's the whole
point). I suppose the most sensible thing to do of a check fails is
to abort the program, given C's lack of exception handling.

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[jacob navia]

Ian Collins wrote:

There are alternatives to C if you want performance and better memory
safety.

Well, that is precisely the issue here.

I think that C should address those problems instead of
telling people:

"C is an obsolete language. Please use another one".

[Ian Collins]

jacob navia wrote:

Ian Collins wrote:

>There are alternatives to C if you want performance and better memory
safety.

Well, that is precisely the issue here.

I think that C should address those problems instead of
telling people:

"C is an obsolete language. Please use another one".

No, it doesn't say that. There is nothing to stop a tool vendor
providing some form of access and leak checking tool. From my
perspective, such a feature is an indication of the quality of their tools.

--
Ian Collins.

[jacob navia]

Guillaume wrote:

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.

(All implementations where it doesn't always
generate an exception, or worse, where it can lead to code execution, is
brain-dead IMO, but that's another story. Thus, it's not a problem of
bounds checking or not.)

You are dreaming!

Most C implementations will not do any bounds checking whatsoever!

2. Bounds checking. You read or write data outside bounds. It generates
an 'out of bounds' exception.

Not that much different. In both cases, you need to handle the
exception. How you must handle it in its particular context really *is*
the main issue here, and the main difficulty.

Yes. The consequence is that we need an exception handling
capability!

"Manual" bounds checking here and there in your code can be useful -
mostly because you know why you want to check that at this point and how
you're gonna handle the occasional out-of-bounds cases.

Exactly.

But systematic bounds checking? I don't believe in that.
You opinion may vary. But I'm waiting for strong arguments.

[dan]

On Jul 29, 2:43 pm, jacob navia <[e-mail]:

We hear very often in this discussion group that
bounds checking, or safety tests are too expensive
to be used in C.

Several researchers of UCSD have published an interesting
paper about this problem.

http://www.jilp.org/vol9/v9paper10.pdf

Specifically, they measured the overhead of a bounds
checking implementation compared to a normal one, and
found that in some cases the overhead can be reduced
to a mere 8.3% in some cases...

I quote from that paper

< quote >
To summarize, our meta-data layout coupled with meta-check instruction
reduce the average overhead of bounds checking to 21% slowdown which is
a significant reduction when compared to 81% incurred by current
software implementations when providing complete bounds checking.
< end quote>

This 21% slowdown is the overhead of checking EACH POINTER
access, and each (possible) dangling pointer dereference.

If we extrapolate to the alleged overhead of using some extra
arguments to strcpy to allow for safer functions (the "evil
empire" proposal) the overhead should be practically ZERO.

Somehow, we are not realizing that with the extreme power of the
CPUs now at our disposal, it is a very good idea to try to
minimize the time we stay behind the debugger when developing
software. A balance should be sought for improving the safety
of the language without overly compromising the speed of the
generated code.

I quote again from that paper:

< quote >
As high GHZ processors become prevalent, adding hardware support to
ensure the correctness and security of programs will be just as
important, for the average user, as further increases in processor
performance. The goal of our research is to focus on developing
compiler and hardware support for efficiently performing software checks
that can be left on all of the time, even in production code releases,
to provide a signi cant increase in the correctness and security of
software.

< end quote >

The C language, as it is perceived by many people here, seems
frozen in the past without any desire to incorporate the changing
hardware/software relationship into the language itself.

When this issues are raised, the "argument" most often presented is
"Efficiency" or just "it is like that".

This has lead to the language being perceived as a backward and error
prone, only good for outdated software or "legacy" systems.

This pleases again the C++ people, that insist in seeing their language
as the "better C", and obviously, C++ is much better in some ways as
C, specially what string handling/common algorithms in the STL/ and
many other advances.

What strikes me is that this need not be, since C could with minimal
improvements be a much safer and general purpose language than it is
now.

Discussion about this possibility is nearly impossible, since a widely
read forum about C (besides this newsgroup) is non existing.

Hence this message.

To summarize:

o Bounds checking and safer, language supported constructs are NOT
impossible because too much overhead
o Constructs like a better run time library could be implemented in a
much safer manner if we would redesign the library from scratch,
without any effective run time cost.

jacob

P.S. If you think this article is off topic, please just ignore it.
I am tired of this stupid polemics.

Is it reasonable to suggest that if you don't think C is safe, or
needs bounds checking, then develop or use another language that is
safer? Or use a tool / development environment that does bounds
checking. I've used Java and C# a lot and really like them. But C is a
different kind of language. One thing I really I like about C is that
it does NOT impose extra overhead, such as mandatory bounds checking,
that the programmer is stuck with. I don't think it makes sense to
make suggestions that would radically change the nature of an existing
programming language.

Daniel Goldman

[jacob navia]

Ian Collins wrote:

jacob navia wrote:

>Ian Collins wrote:

>>There are alternatives to C if you want performance and better memory
safety.

Well, that is precisely the issue here.

I think that C should address those problems instead of
telling people:

"C is an obsolete language. Please use another one".

No, it doesn't say that. There is nothing to stop a tool vendor
providing some form of access and leak checking tool. From my
perspective, such a feature is an indication of the quality of their tools.

Yes, there are a lot of tools, and their existence PROVES the gaping
hole in the language. The problem is that developing such tools
is very system specific and in most cases not available.

o They are NOT available in many embedded platforms
o They are NOT available in many respected systems like,
(for instance) AIX, or SUN, as far as I know. Under linux
you have valgrind but it is quite heavy to use.

What I am aiming at is a general language construct that would
allow more easy compiler checking in the existing toolset,
i.e. the compiler and the linker.

[Richard Heathfield]

Keith Thompson said:

Bjoern Vian <Bj*********@gmx.liwrites:

>Richard Heathfield schrieb:

>>I actually said "strictly conforming program". A strictly conforming
program does not contain any instances of undefined behaviour. (If
it did, it would not be strictly conforming.) Therefore, it cannot
violate any bounds.

Ok, but that is completely irrelevant for programming practice;
it's pure theory.

I agree that the category of "strictly conforming programs" is too
narrow to be particularly useful to programmers. (It's useful
primarily in defining conforming implementations, I think.)

And that's how I was using it in this thread - to illustrate that you
can have bounds-checking conforming implementations right now if you
want.

<snip>

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?
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! :-)

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

[Richard Heathfield]

jacob navia said:

Bjoern Vian wrote:

>Richard Heathfield schrieb:

>>I actually said "strictly conforming program". A strictly conforming
program does not contain any instances of undefined behaviour. (If
it did, it would not be strictly conforming.) Therefore, it cannot
violate any bounds.

Ok, but that is completely irrelevant for programming practice;
it's pure theory.

It is not even theory

What he is saying is:

"A strictly conforming program does not contain any instances of
undefined behavior."

What this abstraction bring to us in useful consequences is
zero since nowhere it is specified how to prove/disprove
that program "a" is strictly conforming or not!

Please learn to read for comprehension. The reason I mentioned strictly
conforming programs at all was to make it clear just why C
implementations are already allowed to offer bounds-checking, even
though the Standard doesn't mention it.

>
But let's close this parentheses. Heathfield posted that
message 9 minutes after I posted mine,

Yes, that's right. It's not difficult to see what you're trying to say:
"wouldn't bounds checking in C be great?" And my answer is equally
simple: "if you want it, you can already have it *today*, and if you
don't want it, you don't have to have it". From a C language
perspective, what else is there to say?

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

[William Hughes]

On Jul 29, 7:17 pm, Ian Collins <[e-mail]:

>
There are alternatives to C if you want performance and better memory
safety.

I am not sure what you are saying here. Are you claiming that
among the existing implementations there is an implementation
of another language that gives you performance and better
memory safety than any existing implementation of C,
or are you claiming that there is another language which gives
performance and better memory safety than any possible
implemntation of C (in this case is the claim that the performance
is comparable to that of C)? Or do you mean something
else?

- William Hughes

[Ian Collins]

jacob navia wrote:

Ian Collins wrote:

>jacob navia wrote:

>>Ian Collins wrote:
There are alternatives to C if you want performance and better memory
safety.

Well, that is precisely the issue here.

I think that C should address those problems instead of
telling people:

"C is an obsolete language. Please use another one".

No, it doesn't say that. There is nothing to stop a tool vendor
providing some form of access and leak checking tool. From my
perspective, such a feature is an indication of the quality of their
tools.

Yes, there are a lot of tools, and their existence PROVES the gaping
hole in the language. The problem is that developing such tools
is very system specific and in most cases not available.

o They are NOT available in many embedded platforms

You can test the code off-target.

o They are NOT available in many respected systems like,
(for instance) AIX, or SUN, as far as I know.

News to me, I've been using Sun's dbx with its access/leak checking for
many years.

>
What I am aiming at is a general language construct that would
allow more easy compiler checking in the existing toolset,
i.e. the compiler and the linker.

Why impost the extra burden on the vendor when they can provides optinal
tools?

--
Ian Collins.

[jacob navia]

dan wrote:

>
Is it reasonable to suggest that if you don't think C is safe, or
needs bounds checking, then develop or use another language that is
safer?

Excuse me but I do not see why I would need another computer
language to write:

int Strcmp(String s1,String s2);

Where String could be defined as:

typedef struct tagString {
size_t len;
char *chars;
};

Why can't we use this in C instead of being stuck with zero
terminated strings forever?

Why can't arrays be first class objects like structures that do NOT
decay into unbounded pointers eliminating all size information and
making size checks impossible?

Or use a tool / development environment that does bounds
checking. I've used Java and C# a lot and really like them.

Nice, but I think that C should give an answer to this problems,
should address this problems instead of saying to people

"Go away and use a real computer language"

But C is a
different kind of language.

Really?

What kind of language then?

One thing I really I like about C is that
it does NOT impose extra overhead, such as mandatory bounds checking,
that the programmer is stuck with.

Pascal has an optional bound checking that can be turned on/off with
specific programmer's instructions.

I don't think it makes sense to
make suggestions that would radically change the nature of an existing
programming language.

int Strcmp(String s1,String s2);

That changes radically the language?

Maybe, I do not know.

In any case if we go on like this the language is doomed.

I remember what happened when I suggested C last time at work.

"It would be incovenient" people told me.

And that was it.

[jacob navia]

Ian Collins wrote:

>o They are NOT available in many embedded platforms

You can test the code off-target.

No. The code will run on target and you would have to
simulate the conditions on target, not always an easy task,
mind you.

>

>o They are NOT available in many respected systems like,
(for instance) AIX, or SUN, as far as I know.

News to me, I've been using Sun's dbx with its access/leak checking for
many years.

Impossible to use because the program will slow down for a factor
of 1,000 at least...

>What I am aiming at is a general language construct that would
allow more easy compiler checking in the existing toolset,
i.e. the compiler and the linker.

Why impost the extra burden on the vendor when they can provides optinal
tools?

Because not every vendor can provide such tools, and a small language
modifications would suffice to provide for most bound
checking applications.

[Keith Thompson]

Guillaume <"grsNOSPAM at NOTTHATmail dot com"writes:

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. (All implementations where it doesn't always
generate an exception, or worse, where it can lead to code execution,
is brain-dead IMO, but that's another story. Thus, it's not a problem
of bounds checking or not.)

[...]

Are you under the impression that attempts to violate bounds in C
typically trigger an exception? In my experience, attempting to
access memory just beyond the bounds of an array *usually* results in
the program silently accessing some other memory, perhaps part of
another object.

Implementations typically catch attempts to access memory outside
what's allocated to a program, but accesses within that memory usually
aren't caught, even if they violate the bounds of the intended object.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

jacob navia <ja***@jacob.remcomp.frwrites:

Bjoern Vian wrote:

>Richard Heathfield schrieb:

>>I actually said "strictly conforming program". A strictly
conforming program does not contain any instances of undefined
behaviour. (If it did, it would not be strictly conforming.)
Therefore, it cannot violate any bounds.

Ok, but that is completely irrelevant for programming practice;
it's pure theory.

It is not even theory

What he is saying is:

"A strictly conforming program does not contain any instances of
undefined behavior."

Of course; that's part of the definition of the term.

What this abstraction bring to us in useful consequences is
zero since nowhere it is specified how to prove/disprove
that program "a" is strictly conforming or not!

No, that's not specified. What's the point?

But let's close this parentheses. Heathfield posted that
message 9 minutes after I posted mine, with some "bla bla"
without substance. He did not read the article of those
researchers, and he addresses NONE of the issues I raised.

Please let's return to those issues!

Huh? You raised the issue of bounds checking in C. He confirmed that
it's already legal to implement bounds checking in C. That seems
relevant to me.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Ian Collins]

jacob navia wrote:

Ian Collins wrote:

>>o They are NOT available in many embedded platforms

You can test the code off-target.

No. The code will run on target and you would have to
simulate the conditions on target, not always an easy task,
mind you.

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.

>>

>>o They are NOT available in many respected systems like,
(for instance) AIX, or SUN, as far as I know.

News to me, I've been using Sun's dbx with its access/leak checking for
many years.

Impossible to use because the program will slow down for a factor
of 1,000 at least...

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.

>>What I am aiming at is a general language construct that would
allow more easy compiler checking in the existing toolset,
i.e. the compiler and the linker.

Why impost the extra burden on the vendor when they can provides optinal
tools?

Because not every vendor can provide such tools, and a small language
modifications would suffice to provide for most bound
checking applications.

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

--
Ian Collins.

[dan]

On Jul 29, 3:49 pm, jacob navia <[e-mail]:

dan wrote:

Is it reasonable to suggest that if you don't think C is safe, or
needs bounds checking, then develop or use another language that is
safer?

Excuse me but I do not see why I would need another computer
language to write:

int Strcmp(String s1,String s2);

Where String could be defined as:

typedef struct tagString {
size_t len;
char *chars;

};

Why can't we use this in C instead of being stuck with zero
terminated strings forever?

Why can't arrays be first class objects like structures that do NOT
decay into unbounded pointers eliminating all size information and
making size checks impossible?

Or use a tool / development environment that does bounds

checking. I've used Java and C# a lot and really like them.

Nice, but I think that C should give an answer to this problems,
should address this problems instead of saying to people

"Go away and use a real computer language"

But C is a
different kind of language.

Really?

What kind of language then?

One thing I really I like about C is that
it does NOT impose extra overhead, such as mandatory bounds checking,
that the programmer is stuck with.

Pascal has an optional bound checking that can be turned on/off with
specific programmer's instructions.

I don't think it makes sense to
make suggestions that would radically change the nature of an existing
programming language.

int Strcmp(String s1,String s2);

That changes radically the language?

Maybe, I do not know.

In any case if we go on like this the language is doomed.

I remember what happened when I suggested C last time at work.

"It would be incovenient" people told me.

And that was it.

It would be great if bounds checking could be turned on or off in C.
But by your example, it's already possible to accomplish that within
the current C language. Instead of calling strcmp directly, just call
it within another function that does the bounds checking. If this is
important to you or someone else, why don't you write a version of the
C library that does bounds checking? My guess is someone else has
already done this. From your example, it seems like your argument is
really to get rid of 0 as the convention for ending a string. You
don't think that would be a radical change? Sounds pretty radical to
me.

real languages??? I never said that C# and Java were "real computer
languages", and that C is not. I just said they are different types of
languages. I've never heard anyone else on this group say that either.
Any who would say C is not a "real computer language" is just plain
stupid.

your place of work??? Maybe it would be inconvenient for them to use C
at your place of work. I have no idea. I don't see what that has to do
with the discussion.

what kind of language??? You ask "What kind of language then?" to my
statement that C is a different kind of language. If you're proposing
fundamental changes to C, and don't understand the huge differences
between C and Java/C# (I assume you really do know the differences),
you need to go back to the basics.

Doomed??? You say that "if we go on like this the language is doomed".
Have you looked at the TIOBE programming index anytime. The last time
I looked, it was #2 or #3 in popularity! I don't think C is doomed.
And what if it is doomed, whatever that means? After all, it's just a
language. If C dies out (no indication of that at present), there
would be another (hopefully better) language to take it's place. Maybe
someone will write a new language like C that will not use 0 to
terminate strings!

Daniel Goldman

[Keith Thompson]

Richard Heathfield <rj*@see.sig.invalidwrites:

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

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

jacob navia <ja***@jacob.remcomp.frwrites:

dan wrote:

>Is it reasonable to suggest that if you don't think C is safe, or
needs bounds checking, then develop or use another language that is
safer?

Excuse me but I do not see why I would need another computer
language to write:

int Strcmp(String s1,String s2);

Where String could be defined as:

typedef struct tagString {
size_t len;
char *chars;
};

Quibble: you forgot the typedef name.

Why can't we use this in C instead of being stuck with zero
terminated strings forever?

We can, of course; who ever said we can't? A number of string
packages are available.

If you're suggesting making radical changes to the language, that
won't do any good until and unless such changes are incorporated into
the standard *and* widely implemented. In the best case, this will
take many years. In the worst case, it will never happen; witness the
lack of adoption of C99.

If you're suggesting dropping C's current support for zero-terminated
strings, that will absolutely never happen; it would break existing
code.

Why can't arrays be first class objects like structures that do NOT
decay into unbounded pointers eliminating all size information and
making size checks impossible?

Because making such a change would break existing code.

If you want a new array-like construct, either you can already
implement it in C, or it requires unrealisticly drastic changes to the
language.

[...]

>I don't think it makes sense to
make suggestions that would radically change the nature of an existing
programming language.

int Strcmp(String s1,String s2);

That changes radically the language?

Maybe, I do not know.

Of course not. That declaration, given an appropriate declaration of
String, is already perfectly legal C.

[...]

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Ian Collins]

Keith Thompson wrote:

jacob navia <ja***@jacob.remcomp.frwrites:

>Why can't arrays be first class objects like structures that do NOT
decay into unbounded pointers eliminating all size information and
making size checks impossible?

Because making such a change would break existing code.

If you want a new array-like construct, either you can already
implement it in C, or it requires unrealisticly drastic changes to the
language.

Those drastic changes have already been made, they're called C++ :)

--
Ian Collins.

[Keith Thompson]

dan <da*******@yahoo.comwrites:
[...]

It would be great if bounds checking could be turned on or off in C.
But by your example, it's already possible to accomplish that within
the current C language. Instead of calling strcmp directly, just call
it within another function that does the bounds checking. If this is
important to you or someone else, why don't you write a version of the
C library that does bounds checking? My guess is someone else has
already done this. From your example, it seems like your argument is
really to get rid of 0 as the convention for ending a string. You
don't think that would be a radical change? Sounds pretty radical to
me.

[...]

A bounds checking implementation of the standard C library is not
possible, at least not without considerable compiler support.

For example, strcmp() just takes two pointers as arguments. Neither
strcmp() nor any theoretical wrapper function has any way of knowing
the sizes of the actual arrays (assuming that each pointer points to
the first element of an array).

Now a wrapper function that takes additional arguments that specify
the sizes of the arrays could check the bounds, but then the caller
would have to pass correct values for those arguments.

And of course changes to the runtime library don't help user code.

A bounds-checking *compiler* can keep track of the sizes of objects by
enhancing pointers with information about what they point to. Using
such a compiler to compile the library (at least a version of it)
(assuming it's written in C) should give you all the bounds checking
you need.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Chris Torek]

In article <46***********************@news.orange.fr>
jacob navia <ja***@jacob.remcomp.frwrote:

>We hear very often in this discussion group that
bounds checking, or safety tests are too expensive
to be used in C.

Some people think it is "too expensive", some do not.

Here are some references to existing bounds-checking implementations
for C compilers.

http://llvm.org/pubs/2006-05-24-SAFE...oundsCheck.pdf

http://gcc.gnu.org/ml/gcc/1998-05/msg00073.html

http://www.pgroup.com/

Of these, I think only the Portland Group's compilers are actually
available today (and they do bounds-checking by default, though you
can turn it off with a pragma; see the user's guide).

The relative un-common-ness of bounds checking implementations
does, I think, say something about the relative demand for such
implementations -- especially since it is so easy to put in a C
compiler, if one is designing one "from the ground" as it were.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[dan]

On Jul 29, 2:43 pm, jacob navia <[e-mail]:

We hear very often in this discussion group that
bounds checking, or safety tests are too expensive
to be used in C.

Several researchers of UCSD have published an interesting
paper about this problem.

http://www.jilp.org/vol9/v9paper10.pdf

Specifically, they measured the overhead of a bounds
checking implementation compared to a normal one, and
found that in some cases the overhead can be reduced
to a mere 8.3% in some cases...

I quote from that paper

< quote >
To summarize, our meta-data layout coupled with meta-check instruction
reduce the average overhead of bounds checking to 21% slowdown which is
a significant reduction when compared to 81% incurred by current
software implementations when providing complete bounds checking.
< end quote>

This 21% slowdown is the overhead of checking EACH POINTER
access, and each (possible) dangling pointer dereference.

If we extrapolate to the alleged overhead of using some extra
arguments to strcpy to allow for safer functions (the "evil
empire" proposal) the overhead should be practically ZERO.

Somehow, we are not realizing that with the extreme power of the
CPUs now at our disposal, it is a very good idea to try to
minimize the time we stay behind the debugger when developing
software. A balance should be sought for improving the safety
of the language without overly compromising the speed of the
generated code.

I quote again from that paper:

< quote >
As high GHZ processors become prevalent, adding hardware support to
ensure the correctness and security of programs will be just as
important, for the average user, as further increases in processor
performance. The goal of our research is to focus on developing
compiler and hardware support for efficiently performing software checks
that can be left on all of the time, even in production code releases,
to provide a signi cant increase in the correctness and security of
software.

< end quote >

The C language, as it is perceived by many people here, seems
frozen in the past without any desire to incorporate the changing
hardware/software relationship into the language itself.

When this issues are raised, the "argument" most often presented is
"Efficiency" or just "it is like that".

This has lead to the language being perceived as a backward and error
prone, only good for outdated software or "legacy" systems.

This pleases again the C++ people, that insist in seeing their language
as the "better C", and obviously, C++ is much better in some ways as
C, specially what string handling/common algorithms in the STL/ and
many other advances.

What strikes me is that this need not be, since C could with minimal
improvements be a much safer and general purpose language than it is
now.

Discussion about this possibility is nearly impossible, since a widely
read forum about C (besides this newsgroup) is non existing.

Hence this message.

To summarize:

o Bounds checking and safer, language supported constructs are NOT
impossible because too much overhead
o Constructs like a better run time library could be implemented in a
much safer manner if we would redesign the library from scratch,
without any effective run time cost.

jacob

P.S. If you think this article is off topic, please just ignore it.
I am tired of this stupid polemics.

I read (or tried to read) the article. It does not suggest changing
the C language. I don't think you understood much of the article, if
you read their conclusions carefully. You totally missed the point
that the authors said hardware changes would be needed to make the
bounds checking not use excessive resources. Maybe it would have been
better if your original post was ignored, since it was so poorly
thought out. Nobody disagrees that messing up pointer and array
operations in C produces very nasty bugs, and that there is a need to
reduce the risk. But your idea about changing the C language to get
rid of strings ending with 0 is totally unworkable, because it would
break tons of existing code, as others have pointed out.

Daniel Goldman

[Richard Bos]

Bjoern Vian <Bj*********@gmx.liwrote:

Richard Heathfield schrieb:

I actually said "strictly conforming program". A strictly conforming
program does not contain any instances of undefined behaviour. (If it
did, it would not be strictly conforming.) Therefore, it cannot violate
any bounds.

Ok, but that is completely irrelevant for programming practice;
it's pure theory.

No, it isn't. If it _were_ possible for a strictly conforming program to
violate object bounds, a bounds checking implementation would be legal.
Since it is _not_ possible, a bounds checking implementation is legal
and, get this, on occasion very _practical_ to discover where your
program is not strictly conforming in a bounds-violating way.

Richard

[Richard Heathfield]

Richard Bos said:

<snip>

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

ITYM "illegal". A mere typo, of course, but it completely reverses the
meaning of the sentence! (We've all done it.)

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

[jacob navia]

Richard Bos wrote:

Bjoern Vian <Bj*********@gmx.liwrote:

>Richard Heathfield schrieb:

>>I actually said "strictly conforming program". A strictly conforming
program does not contain any instances of undefined behaviour. (If it
did, it would not be strictly conforming.) Therefore, it cannot violate
any bounds.

Ok, but that is completely irrelevant for programming practice;
it's pure theory.

No, it isn't. If it _were_ possible for a strictly conforming program to
violate object bounds, a bounds checking implementation would be legal.
Since it is _not_ possible, a bounds checking implementation is legal
and, get this, on occasion very _practical_ to discover where your
program is not strictly conforming in a bounds-violating way.

Richard

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!

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

[jacob navia]

dan wrote:

I read (or tried to read) the article. It does not suggest changing
the C language.

I did not said it was. I cited some of their conclusions, specifically
those that proved that the overhead of bounds checking and dangling
pointer testing could be substantially reduced.

I don't think you understood much of the article,

???

if
you read their conclusions carefully. You totally missed the point
that the authors said hardware changes would be needed to make the
bounds checking not use excessive resources.

They do not said that. They say that a hardware support would be
better to have, but that other things like storing the meta-data
with the object instead of in the pointer would speed things
according to their simulations.

Maybe it would have been
better if your original post was ignored, since it was so poorly
thought out.

Yes, I see that you disagree with the post

Nobody disagrees that messing up pointer and array
operations in C produces very nasty bugs, and that there is a need to
reduce the risk.

This contradicts your earlier sentence...

But your idea about changing the C language to get
rid of strings ending with 0 is totally unworkable, because it would
break tons of existing code, as others have pointed out.

I never said that I wanted to make zero terminated strings illegal.
I just propose that OTHER types of strings could be as well supported by
the language, nothing else.

[Richard]

Richard Heathfield <rj*@see.sig.invalidwrites:

Richard said:

>Richard Heathfield <rj*@see.sig.invalidwrites:

<snip>

>>A strictly conforming
program does not contain any instances of undefined behaviour. (If it
did, it would not be strictly conforming.) Therefore, it cannot
violate any bounds.

How does a program get so certified?

"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]

In article <46**********************@news.orange.fr>,
jacob navia <ja***@jacob.remcomp.frwrote:
....

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

In article <46**********************@news.orange.fr>,
jacob navia <ja***@jacob.remcomp.frwrote:

>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
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Richard]

rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

Bjoern Vian <Bj*********@gmx.liwrote:

>Richard Heathfield schrieb:

I actually said "strictly conforming program". A strictly conforming
program does not contain any instances of undefined behaviour. (If it
did, it would not be strictly conforming.) Therefore, it cannot violate
any bounds.

Ok, but that is completely irrelevant for programming practice;
it's pure theory.

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]

"jacob navia" <ja***@jacob.remcomp.frwrote in message
news:46***********************@news.orange.fr...

Guillaume wrote:

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

jacob navia wrote, On 30/07/07 10:40:

Richard Bos wrote:

>Bjoern Vian <Bj*********@gmx.liwrote:

>>Richard Heathfield schrieb:

I actually said "strictly conforming program". A strictly conforming
program does not contain any instances of undefined behaviour. (If
it did, it would not be strictly conforming.) Therefore, it cannot
violate any bounds.
Ok, but that is completely irrelevant for programming practice;
it's pure theory.

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

As another poster pointed out you meant bounds checking would be illegal.

>Since it is _not_ possible, a bounds checking implementation is legal
and, get this, on occasion very _practical_ to discover where your
program is not strictly conforming in a bounds-violating way.

Richard

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!
--
Flash Gordon

[Flash Gordon]

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

jacob navia wrote:

>Ian Collins wrote:

>>>o They are NOT available in many embedded platforms
You can test the code off-target.

No. The code will run on target and you would have to
simulate the conditions on target, not always an easy task,
mind you.

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.

<snip>

>>>What I am aiming at is a general language construct that would
allow more easy compiler checking in the existing toolset,
i.e. the compiler and the linker.
Why impost the extra burden on the vendor when they can provides optinal
tools?

Because not every vendor can provide such tools, and a small language
modifications would suffice to provide for most bound
checking applications.

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

[Richard Heathfield]

jacob navia said:

<snip>

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

[Richard Heathfield]

Richard said:

<snip>

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

[Richard Heathfield]

Flash Gordon said:

<snip>

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

[Richard]

Richard Heathfield <rj*@see.sig.invalidwrites:

Richard said:

<snip>

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

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]

Ian Collins wrote:

jacob navia wrote:

>Ian Collins wrote:

>>>o They are NOT available in many embedded platforms
You can test the code off-target.

No. The code will run on target and you would have to
simulate the conditions on target, not always an easy task,
mind you.

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.

>

>>>o They are NOT available in many respected systems like,
(for instance) AIX, or SUN, as far as I know.
News to me, I've been using Sun's dbx with its access/leak checking for
many years.

Impossible to use because the program will slow down for a factor
of 1,000 at least...

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

>>>What I am aiming at is a general language construct that would
allow more easy compiler checking in the existing toolset,
i.e. the compiler and the linker.
Why impost the extra burden on the vendor when they can provides optinal
tools?

Because not every vendor can provide such tools, and a small language
modifications would suffice to provide for most bound
checking applications.

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]

Richard wrote:

Richard Heathfield <rj*@see.sig.invalidwrites:

>Richard said:

>>Richard Heathfield <rj*@see.sig.invalidwrites:

<snip>

>>>A strictly conforming
program does not contain any instances of undefined behaviour. (If it
did, it would not be strictly conforming.) Therefore, it cannot
violate any bounds.
How does a program get so certified?

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

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

[¬a\\/b]

On Sun, 29 Jul 2007 20:10:48 -0700, dan <da*******@yahoo.comwrote:

>On Jul 29, 2:43 pm, jacob navia <[e-mail]:

>We hear very often in this discussion group that
bounds checking, or safety tests are too expensive
to be used in C.

Several researchers of UCSD have published an interesting
paper about this problem.

http://www.jilp.org/vol9/v9paper10.pdf

Specifically, they measured the overhead of a bounds
checking implementation compared to a normal one, and
found that in some cases the overhead can be reduced
to a mere 8.3% in some cases...

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

[Richard Tobin]

In article <jn********************************@4ax.com>, ¬a\\/b <[e-mail]:

>>Specifically, they measured the overhead of a bounds
checking implementation compared to a normal one, and
found that in some cases the overhead can be reduced
to a mere 8.3% in some cases...

>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
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.