Criticisms?

[Zach]

Can someone give a detailed rejoinder to this. Would also be nice if
someone updates the wiki page so that readers get the other perspective
and don't get the wrong impression about C:

http://en.wikipedia.org/wiki/Critici...mming_language

Zach

[user923005]

Zach wrote:

Can someone give a detailed rejoinder to this. Would also be nice if
someone updates the wiki page so that readers get the other perspective
and don't get the wrong impression about C:

http://en.wikipedia.org/wiki/Critici...mming_language

All of the criticisms look valid to me.

On the other hand, some of the criticisms are both features and
problems at the same time.

An example is garbage collection. Languages that have GC are
problematic for real-time stuff because GC can suddenly hog big chunks
of CPU at surprising times. (Aside: Let's not start up that real-time
Java stuff again, please).

Consider array bounds checking -- C doesn't do it. But those sorts of
operations take time. If you always check the bounds of an array to
see if the element you are assigning belongs in that slot, then the
operation will have to be slower.

But in general, I think all of those criticisms are accurate and things
we should think about when choosing a language and when writing a
program in C, if C is the language chosen.

[David T. Ashley]

"Zach" <ne****@gmail.comwrote in message
news:11**********************@a75g2000cwd.googlegr oups.com...

Can someone give a detailed rejoinder to this. Would also be nice if
someone updates the wiki page so that readers get the other perspective
and don't get the wrong impression about C:

http://en.wikipedia.org/wiki/Critici...mming_language

The URL is 65% trash.

All I'm going to say is that there are reasons 'C' compiles well. 90% of
the "weaknesses" listed on that page are actually strengths.

--
David T. Ashley (dt*@e3ft.com)
http://www.e3ft.com (Consulting Home Page)
http://www.dtashley.com (Personal Home Page)
http://gpl.e3ft.com (GPL Publications and Projects)

[Richard Heathfield]

Zach said:

Can someone give a detailed rejoinder to this. Would also be nice if
someone updates the wiki page so that readers get the other perspective
and don't get the wrong impression about C:

http://en.wikipedia.org/wiki/Critici...mming_language

Updating the wiki is like spitting in the wind. The only effective
alteration to the universe is that you end up with spit on your face.

"Many beginning programmers have difficulty learning C's syntax and
peculiarities, and even many expert programmers find C programs difficult
to maintain and debug" - maintenance and debugging are harder than
development, and most people don't exactly go out of their way to write
maintenance-friendly code. This is a people problem, not a C program. As
for beginners, frankly some of them would have difficulty punching their
way out of a paper bag, and C cannot be blamed for that. Poor tutorials
don't help, however.

"In other words, C permits many operations that are generally not
desirable," because stopping people doing stupid things can also stop them
doing clever things.

"This potentially leads to programs with unpredictable behavior and security
holes," and potentially leads to programs of breathtaking brilliance,
clarity and speed, too.

"if sufficient care and discipline are not used in programming and
maintenance." So take sufficient care, and use sufficient discipline. This
is necessary in *all* programming languages.

"The designers wanted to avoid compile- and run-time checks that were too
expensive when C was first implemented." Oh, and nowadays, of course,
software is ***sooooo fast*** that these checks can be added willy-nilly,
right? I Don't Think So. Gates's Law and all that.

"No automatic copying of arrays or strings (but structs are automatically
copied)" - GOOD! Why on earth would I want arrays or strings to be
duplicated all over the place? What a waste of memory.

"No automatic garbage collection" - GOOD! If you want AGC and can live with
the overhead, various implementations offer it as an add-on. If you don't,
why should you let it be forced upon you?

"No bounds checking of arrays and allocated memory segments" - GOOD! If you
want ABC and can live with the overhead, various implementations offer it
as an add-on. If you don't, why should you let it be forced upon you?

"No operations on whole arrays" - true enough, but so what? The existence of
a feature in language A does not make its omission a weakness of language
B.

"No semi-dynamic (i.e. stacked, runtime-sized) arrays until the C99 standard
(despite not requiring garbage collection)" - it's a shame that C99 has
introduced this pointless feature. C already has the facility to create
arrays at runtime *with failure detection*, and so a facility that lacks
failure detection seems rather silly.

"No syntax for ranges, such as the A..B notation used in both newer and
older languages" - unnecessary, given the simplicity of memcpy(p + i, q +
j, n);

"No nested function definitions (although some compilers provide them, for
example, GCC)" - so what? The existence of a feature in language A does not
make its omission a weakness of language B.

"No foo (for various other values of foo)" - again, it has not been
demonstrated that the lack of foo is a weakness. And, as the wiki admits
(at the present moment, at least), "although the list of built-in features
C lacks is long, this has contributed significantly to its acceptance". Go
figure.

"C draws criticism because its standard explicitly identifies numerous cases
of undefined behavior, including some where the behavior could have been
made well defined, and does not specify any run-time error handling
mechanism." - the behaviour can *always* be made well-defined, but to do so
unnecessarily limits optimisation potential and *prevents* the provision of
third-party libraries. A language where everything is nailed down is an
unextensible language.

"One issue to be aware of when using C is that automatically and dynamically
allocated objects are not necessarily initialized" - true, and that's a
feature, not a bug. The wiki continues (at present): "Another common
problem", which begs the question that non-initialisation is necessarily a
problem. Personally, I'm in favour of initialising everything, *but* I
recognise that C is a language that offers us *choice*. If I want to
initialise everything, that's *my choice*. If other people don't want to,
that's *their* choice.

This "Another common problem", by the way, is basically oh deary deary me,
isn't memory management hard, why not let the system do it? Answer: if you
want automatic memory management, you know where to find it.

"Pointers are a primary source of potential danger." - So are cars. If you
can't handle a car safely, don't drive. Please. But just because you can't
drive, that does not mean other people can't.

And so on and so on. Sorry, I did intend to answer each point, but I'm only
a third the way down the wiki page as presently constituted, this article
is already just about a hundred lines long, and in any case I have not
found a *single* valid crit yet. If you are asked to find all the gold
coins in a three-mile-long pile of pigeon guano, and you plough through an
entire mile of ordure without finding any gold coins, you might just feel
like giving up yourself.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Ian Collins]

Richard Heathfield wrote:

>
"No semi-dynamic (i.e. stacked, runtime-sized) arrays until the C99 standard
(despite not requiring garbage collection)" - it's a shame that C99 has
introduced this pointless feature. C already has the facility to create
arrays at runtime *with failure detection*, and so a facility that lacks
failure detection seems rather silly.

Do you think the common Unix function alloca(), which allocates memory
from the stack should have been standardised?

It can be a direct replacement for VLAs with failure detection and I've
often wondered why it wasn't included in the standard library.

--
Ian Collins.

[Richard Heathfield]

Ian Collins said:

Richard Heathfield wrote:

>>
"No semi-dynamic (i.e. stacked, runtime-sized) arrays until the C99
standard (despite not requiring garbage collection)" - it's a shame that
C99 has introduced this pointless feature. C already has the facility to
create arrays at runtime *with failure detection*, and so a facility that
lacks failure detection seems rather silly.

Do you think the common Unix function alloca(), which allocates memory
from the stack should have been standardised?

I don't mind either way. I have no particular use for it, but maybe others
would have found a use. Possibly one or two implementors (perhaps on
stackless systems) would baulk, but it wouldn't /have/ to use a stack - it
could just use whatever auto objects use.

It can be a direct replacement for VLAs with failure detection and I've
often wondered why it wasn't included in the standard library.

You might want to ask in csc - but perhaps the answer is as simple as "oh,
we never thought of that".

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[user923005]

Ian Collins wrote:

Richard Heathfield wrote:

"No semi-dynamic (i.e. stacked, runtime-sized) arrays until the C99 standard
(despite not requiring garbage collection)" - it's a shame that C99 has
introduced this pointless feature. C already has the facility to create
arrays at runtime *with failure detection*, and so a facility that lacks
failure detection seems rather silly.

Do you think the common Unix function alloca(), which allocates memory
from the stack should have been standardised?

It can be a direct replacement for VLAs with failure detection and I've
often wondered why it wasn't included in the standard library.

I guess it is because not all computers have a stack.

[Chris Torek]

>Richard Heathfield wrote:

>>"No semi-dynamic (i.e. stacked, runtime-sized) arrays until the
C99 standard (despite not requiring garbage collection)" - it's a
shame that C99 has introduced this pointless feature. C already
has the facility to create arrays at runtime *with failure detection*,
and so a facility that lacks failure detection seems rather silly.

Actually, VLAs give you more than just that one particular feature.
In particular, you can now use VLAs to handle multidimensional
array parameters conveniently:

void mat_whatever(size_t nrows, size_t ncols, double mat[nrows][ncols]) {
... operation on the matrix mat ...
}

Although this is usually do-able in C89, you have to at least
technically violate array bounds if you work on an actual matrix
(i.e., pass &mat[0][0] in the caller, and do and your own "manual"
indexing, accessing p[r * ncols + c], to get at mat[r][c]).

In article <51**************@mid.individual.net>
Ian Collins <ia******@hotmail.comwrote:

>Do you think the common Unix function alloca(), which allocates memory
from the stack should have been standardised?

It can be a direct replacement for VLAs with failure detection and I've
often wondered why it wasn't included in the standard library.

For alloca() to be reliable, the compiler has to recognize calls
to it. Try something like:

foo(bar(),
128, alloca(128),
baz(i, alloca(i), j),
32, alloca(32),
zog(42));

on a straightforward Intel x86 compiler that does not recognize
alloca(), for instance, and then observe the carnage. :-) (The
problem is that each alloca() call adjusts the stack while the
compiler is building the stack that is going to be used to call
the functions involved. The stack thus built interleaves "alloca
created stack space" with "compiler created stack space", and
everything goes haywire when pieces of this are removed. Note
also that the behavior tends to change with optimization levels,
when post-function-call stack adjustments may be deferred.)

Given that alloca() must, in order to be reliable, be a compiler
built-in, I believe it makes more sense to just have VLAs as a
compiler built-in.

Note that the duration of VLAs is well-controlled and interacts
"correctly" with other block-scope variables:

for (int i = k; i < max; i += step) {
double a, b, tmp[i];
...
if (finished)
break;
...
}

but this is not true for alloca() space:

for (int i = k; i < max; i++) {
double a, b, *tmp;

tmp = alloca(i * sizeof *tmp);
...
if (finished)
break;
...
/* tmp is too small, we should get rid of it here */
/* unalloca(tmp); -- there is no way to do this */
}

While it is possible to come up with cases where "function duration"
objects -- what alloca() produces, if it works at all -- are useful,
this seems to be considerably rarer than normal automatic-duration
(block scope automatic) variables.
--
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.

[Kenny McCormack]

In article <Xf******************************@giganews.com>,
David T. Ashley <dt*@e3ft.comwrote:

>"Zach" <ne****@gmail.comwrote in message
news:11**********************@a75g2000cwd.googleg roups.com...

>Can someone give a detailed rejoinder to this. Would also be nice if
someone updates the wiki page so that readers get the other perspective
and don't get the wrong impression about C:

http://en.wikipedia.org/wiki/Critici...mming_language

The URL is 65% trash.

All I'm going to say is that there are reasons 'C' compiles well. 90% of
the "weaknesses" listed on that page are actually strengths.

83% of all statistics are made up.

[Ben Bacarisse]

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

"C draws criticism because its standard explicitly identifies numerous cases
of undefined behavior, including some where the behavior could have been
made well defined, and does not specify any run-time error handling
mechanism." - the behaviour can *always* be made well-defined, but to do so
unnecessarily limits optimisation potential and *prevents* the provision of
third-party libraries. A language where everything is nailed down is an
unextensible language.

I think you are sightly overstating this case. If the standard
changed feature X from "undefined behaviour" to "implementation
defined" I can't see that this would hinder (you say *prevents*) any
third party library. I agree with the last point, but nailing
everything down is not the only alternative to UB.

What it would do is allow beginners to write

#include <stdio.h>

int main(void)
{
int degrees_c;
scanf("%d", &degrees_c);
printf("...is %d in Fahrenheit.\n", (degrees_c * 9) / 5 + 32);
}

without writing something that is as undefined as, say, using gets.
We all know that this program is safer than one that uses gets, but
the standard does not say so and, to use your version of UB, nuclear
war may result from running it.

--
Ben.

[Richard Heathfield]

Ben Bacarisse said:

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

>"C draws criticism because its standard explicitly identifies numerous
cases of undefined behavior, including some where the behavior could have
been made well defined, and does not specify any run-time error handling
mechanism." - the behaviour can *always* be made well-defined, but to do
so unnecessarily limits optimisation potential and *prevents* the
provision of third-party libraries. A language where everything is nailed
down is an unextensible language.

I think you are sightly overstating this case. If the standard
changed feature X from "undefined behaviour" to "implementation
defined" I can't see that this would hinder (you say *prevents*) any
third party library. I agree with the last point, but nailing
everything down is not the only alternative to UB.

Implementation-defined behaviour requires that the implementation document
the choice that it has made (3.4.1 of C99, 1.6 in C89). As it stands at the
moment, the C Standard doesn't define the effect on the abstract machine of
calling functions to which the source code is not available, unless they
are standard library functions. Thus, the following program exhibits
undefined behaviour:

#include <thirdpartylibrary.h>
int main(void)
{
thirdpartyfunction();
return 0;
}

To make this program exhibit implementation-defined behaviour instead, every
implementation would have to document what thirdpartyfunction() does, even
if they didn't supply such a function.

What it would do is allow beginners to write

#include <stdio.h>

int main(void)
{
int degrees_c;
scanf("%d", &degrees_c);
printf("...is %d in Fahrenheit.\n", (degrees_c * 9) / 5 + 32);
}

without writing something that is as undefined as, say, using gets.
We all know that this program is safer than one that uses gets, but
the standard does not say so and, to use your version of UB, nuclear
war may result from running it.

I hope that beginners would not write code like that, but I know that they
do. Yes, the program is safer than one containing a call to gets.
Nevertheless, it fails to check whether the degrees_c object has been
correctly populated, and it fails to check for overflow possibilities
before performing the multiplication.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[jacob navia]

Zach a écrit :

Can someone give a detailed rejoinder to this. Would also be nice if
someone updates the wiki page so that readers get the other perspective
and don't get the wrong impression about C:

http://en.wikipedia.org/wiki/Critici...mming_language

Zach

Many of the criticisms look very valid to me.
We have discussed several of those, and I think that that page provides
useful information to the reader.

I disagree that we need closures, or similar constructs, but this
is a matter of opinion. The writer has a different opinion.

The critic about arrays handling in C (one of the weakness of the
language) is perfectly valid.

jacob

[Ben Bacarisse]

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

Ben Bacarisse said:

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

>>"C draws criticism because its standard explicitly identifies numerous
cases of undefined behavior, including some where the behavior could have
been made well defined, and does not specify any run-time error handling
mechanism." - the behaviour can *always* be made well-defined, but to do
so unnecessarily limits optimisation potential and *prevents* the
provision of third-party libraries. A language where everything is nailed
down is an unextensible language.

I think you are sightly overstating this case. If the standard
changed feature X from "undefined behaviour" to "implementation
defined" I can't see that this would hinder (you say *prevents*) any
third party library. I agree with the last point, but nailing
everything down is not the only alternative to UB.

Implementation-defined behaviour requires that the implementation document
the choice that it has made (3.4.1 of C99, 1.6 in C89). As it stands at the
moment, the C Standard doesn't define the effect on the abstract machine of
calling functions to which the source code is not available, unless they
are standard library functions. Thus, the following program exhibits
undefined behaviour:

#include <thirdpartylibrary.h>
int main(void)
{
thirdpartyfunction();
return 0;
}

To make this program exhibit implementation-defined behaviour instead, every
implementation would have to document what thirdpartyfunction() does, even
if they didn't supply such a function.

You seem to be making an argument against removing all UB from the
standard or at least from making the specific feature you cite (a
function with unknown source) implementation defined rather than UB.
That was not the argument I was making. Was I not clear or did I
miss-understand you twice?

>What it would do is allow beginners to write

#include <stdio.h>

int main(void)
{
int degrees_c;
scanf("%d", &degrees_c);
printf("...is %d in Fahrenheit.\n", (degrees_c * 9) / 5 + 32);
}

without writing something that is as undefined as, say, using gets.
We all know that this program is safer than one that uses gets, but
the standard does not say so and, to use your version of UB, nuclear
war may result from running it.

I hope that beginners would not write code like that, but I know that they
do. Yes, the program is safer than one containing a call to gets.
Nevertheless, it fails to check whether the degrees_c object has been
correctly populated, and it fails to check for overflow possibilities
before performing the multiplication.

.... and from possible overflow in the %d conversion. But by making
these three implementation defined, lots of programs would become
unpredictable in well-specified situations and safe in others. It
would not be "nuclear".

I can well see that, for example, illegal use of a pointer should be
UB, but I can't see the down side in making signed arithmetic or %d
input implementation defined. Of course, I was not on the committee
and there may have been a down side. I am just saying that I can't
see it. [The third UB -- input error causing scanf to be unable to
convert a valid integer -- I am agnostic about. Students need to
learn about conditionals and to test for input so early that it is not
really a problem.]

Equally, in order to stop this thread from growing forever, I accept
that this is a small point since in "real" programs these problems
have to be solved and the solution can be made re-usable, so the cost
to programmers is tiny. It is as an ex-teacher that I wince at what
needs to be done to re-write the above without UB.

--
Ben.

[Richard Heathfield]

Ben Bacarisse said:

<snip>

>
That was not the argument I was making. Was I not clear or did I
miss-understand you twice?

Perhaps I misunderstood you instead. The possibility, however, remote, must
be faced boldly. ;-)

<snip>

I can well see that, for example, illegal use of a pointer should be
UB, but I can't see the down side in making signed arithmetic or %d
input implementation defined. Of course, I was not on the committee
and there may have been a down side. I am just saying that I can't
see it.

Reasonable point. But on the other hand, like you, I wasn't on the
committee. I am okay with it being UB, and I'd be okay with it being IDB. I
really don't mind either way. If implementors' or optimisers' lives are
made easier by it being UB, that's fine by me.

It is as an ex-teacher that I wince at what
needs to be done to re-write the above without UB.

Yes. There's robust code, and there's easy-for-students code, and they are
rarely the same.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[mark_bluemel]

Zach wrote:

Can someone give a detailed rejoinder to this. Would also be nice if
someone updates the wiki page so that readers get the other perspective
and don't get the wrong impression about C:

http://en.wikipedia.org/wiki/Critici...mming_language

I'm just reminded of Winston Churchill's comment - "Democracy is the
worst form of government, except for all those other forms that have
been tried from time to time."

I can see little point in getting involved in any kind of Wiki editing
here. Richard Heathfield's comment about liquids and stiff breezes
seems to apply, together with the common saw about trying to teach a
pig to sing...

[David T. Ashley]

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:1t*********************@bt.com...

Zach said:

>Can someone give a detailed rejoinder to this. Would also be nice if
someone updates the wiki page so that readers get the other perspective
and don't get the wrong impression about C:

http://en.wikipedia.org/wiki/Critici...mming_language

Updating the wiki is like spitting in the wind. The only effective
alteration to the universe is that you end up with spit on your face.

"Many beginning programmers have difficulty learning C's syntax and
peculiarities, and even many expert programmers find C programs difficult
to maintain and debug" - maintenance and debugging are harder than
development, and most people don't exactly go out of their way to write
maintenance-friendly code. This is a people problem, not a C program. As
for beginners, frankly some of them would have difficulty punching their
way out of a paper bag, and C cannot be blamed for that. Poor tutorials
don't help, however.

"In other words, C permits many operations that are generally not
desirable," because stopping people doing stupid things can also stop them
doing clever things.

snip

It reminds me a lot of RPN calculators. I love them, but I typically get
endless complaints when I loan them out. Some people simply weren't made to
deal with concepts like a stack and the concept of operations that operate
on the bottom two elements and replace them with one element.

I see 'C' in the same way. Some people just were not made to play without a
net. If you can't read your code carefully after you've written it to look
for errors, can't unit-test it, can't adopt prudent programming practices
.... then you ought to be programming in a language that is more idiot-proof.

I can't believe on that page that they mentioned a topic such as terseness.
If you're a professional programmer, you want to minimize typing (it just
wastes time). I think the block begin and end tokens in 'C' ( { and } )
were especially brilliant -- nothing could be terser. A statement that the
language can be cryptic ... is unfounded. I'm grateful that the language
allows things such as "y = x++" or for "(x=0, y=10, z+=22; ...". The bottom
line is that you have to take the time to understand the rules -- same as an
RPN calculator.

Some people just weren't made for 'C'. I'm not sure it is worthwhile to
convince them.
--
David T. Ashley (dt*@e3ft.com)
http://www.e3ft.com (Consulting Home Page)
http://www.dtashley.com (Personal Home Page)
http://gpl.e3ft.com (GPL Publications and Projects)

[David T. Ashley]

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

Zach a écrit :

>Can someone give a detailed rejoinder to this. Would also be nice if
someone updates the wiki page so that readers get the other perspective
and don't get the wrong impression about C:

http://en.wikipedia.org/wiki/Critici...mming_language

Zach

Many of the criticisms look very valid to me.
We have discussed several of those, and I think that that page provides
useful information to the reader.

I disagree that we need closures, or similar constructs, but this
is a matter of opinion. The writer has a different opinion.

The critic about arrays handling in C (one of the weakness of the
language) is perfectly valid.

The array-handling is not a weakness. (It is only a weakness if you can't
write correct code.)

Array bounds checking carries with it the need for additional run-time code,
and penalizes execution time. That isn't right in every application. 'C'
compiles quite well precisely because it omits this kind of overhead.

The pointer and array handling in 'C' is usable, but still maps quite well
to the underlying machine.

The original authors got it right.

The second-guessers 40 years after the fact still aren't getting it.
--
David T. Ashley (dt*@e3ft.com)
http://www.e3ft.com (Consulting Home Page)
http://www.dtashley.com (Personal Home Page)
http://gpl.e3ft.com (GPL Publications and Projects)

[jacob navia]

David T. Ashley a écrit :

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

>>Zach a écrit :

>>>Can someone give a detailed rejoinder to this. Would also be nice if
someone updates the wiki page so that readers get the other perspective
and don't get the wrong impression about C:

http://en.wikipedia.org/wiki/Critici...mming_language

Zach

Many of the criticisms look very valid to me.
We have discussed several of those, and I think that that page provides
useful information to the reader.

I disagree that we need closures, or similar constructs, but this
is a matter of opinion. The writer has a different opinion.

The critic about arrays handling in C (one of the weakness of the
language) is perfectly valid.

The array-handling is not a weakness. (It is only a weakness if you can't
write correct code.)

"Correct" meaning to you that all size information is discarded by the
compiler by default and must be passed again and again as a separate
argument with multiple occasions for errors.

Correct means that

int fn(int array[40])
{
// Here sizeof(array) is equal to a sizeof pointer
}

This *coould* be justified in a PDP-11, but it is surely no longer
justified today with machines 10 000 or more faster than a PDP-11.

Array bounds checking carries with it the need for additional run-time code,
and penalizes execution time.

Obviously random memory overwrites are much faster.

Yeah!

That isn't right in every application. 'C'
compiles quite well precisely because it omits this kind of overhead.

Who wants it in every application? It could be optional, as is in
Pascal.

The pointer and array handling in 'C' is usable, but still maps quite well
to the underlying machine.

Sorry can't parse that sentence.

PARSE ERROR :-)

The original authors got it right.

The second-guessers 40 years after the fact still aren't getting it.

Yes of course. MY C, RIGHT OR WRONG...

40 years later the language needs evolving and accepting the fact that
an operation or a data structure that was OK for THAT time doesn't fit
into today's machines with vastly more ressources than in those
times.

This conservative attitude ah so popular in this group leads to the
demise of the language.

[Kenneth Brody]

Ben Bacarisse wrote:

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

"C draws criticism because its standard explicitly identifies numerous cases
of undefined behavior, including some where the behavior could have been
made well defined, and does not specify any run-time error handling
mechanism." - the behaviour can *always* be made well-defined, but to do so
unnecessarily limits optimisation potential and *prevents* the provision of
third-party libraries. A language where everything is nailed down is an
unextensible language.

I think you are sightly overstating this case. If the standard
changed feature X from "undefined behaviour" to "implementation
defined" I can't see that this would hinder (you say *prevents*) any
third party library. I agree with the last point, but nailing
everything down is not the only alternative to UB.

[...]

The problem with changing all of the "undefined behavior" items in
the standard to "implementation defined" is that you have now placed
a great burden on the implementor to actually define the behavior.
Consider the simple case of modifying something more than once
between sequence points. While it may be easy to define "i=i++;",
consider how many different ways this particular UB can be invoked.
Do you really want to have to define exactly what will happen, and
make sure that the same things happen regardless of optimization?
Not to mention the bad feelings when you redefine the behavior in
the next release, because it works better with the optimization.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Keith Thompson]

Chris Torek <no****@torek.netwrites:
[...]

Given that alloca() must, in order to be reliable, be a compiler
built-in, I believe it makes more sense to just have VLAs as a
compiler built-in.

[...]

I was about to say that alloca() has the advantage that it tells you
if it failed. But then I read the man page (on a Linux system):

void *alloca(size_t size);
[...]
The alloca function returns a pointer to the beginning of the
allocated space. If the allocation causes stack overflow, program
behaviour is undefined.

The Solaris man page has similar wording.

Ick!

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

[kyle york]

Greetings,

jacob navia wrote:

>
"Correct" meaning to you that all size information is discarded by the
compiler by default and must be passed again and again as a separate
argument with multiple occasions for errors.

Correct means that

int fn(int array[40])
{
// Here sizeof(array) is equal to a sizeof pointer
}

This *coould* be justified in a PDP-11, but it is surely no longer
justified today with machines 10 000 or more faster than a PDP-11.

Can you say embedded? You know, processors with 1 - 8K ROM and maybe a
couple of hundred bytes of RAM.

>

>Array bounds checking carries with it the need for additional run-time
code, and penalizes execution time.

Obviously random memory overwrites are much faster.

Only if you're incapable of writing correct code.

>
This conservative attitude ah so popular in this group leads to the
demise of the language.

Yes, clearly C is in demise.

--
Kyle A. York
Sr. Subordinate Grunt

[Richard Heathfield]

jacob navia said:

David T. Ashley a écrit :

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

>>>The critic about arrays handling in C (one of the weakness of the
language) is perfectly valid.

The array-handling is not a weakness. (It is only a weakness if you
can't write correct code.)

"Correct" meaning to you that all size information is discarded by the
compiler by default

No, that would be incorrect. A compiler is not *allowed* to discard size
information for an array until it discards the array itself when it drops
out of scope.

Why don't you learn the language, for pity's sake?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Ben Pfaff]

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

A compiler is not *allowed* to discard size information for an
array until it discards the array itself when it drops out of
scope.

I don't really think that's necessarily true. To be more
precise, it's true at compile-time--the compiler has to be
prepared to support "sizeof" on the array--but not necessarily at
runtime. At runtime, the compiler has to remember where the base
of the array is (at least if the array might be referred to
again), but it doesn't necessarily have to remember how big it
is, because it won't necessarily need that information to release
it. For example, if automatic arrays are allocated by
decrementing the stack pointer, as they often are on x86, then
they are usually freed along with the rest of the automatic
variables for the block or the function in a single lump, with no
separate per-variable or per-array accounting.

The Standard doesn't distinguish between compile time and
runtime, so perhaps this is all nonsense from the Standard's
point of view.
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}

[Richard Heathfield]

Ben Pfaff said:

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

>A compiler is not *allowed* to discard size information for an
array until it discards the array itself when it drops out of
scope.

I don't really think that's necessarily true. To be more
precise, it's true at compile-time--the compiler has to be
prepared to support "sizeof" on the array--but not necessarily at
runtime. At runtime, the compiler has to remember where the base
of the array is (at least if the array might be referred to
again), but it doesn't necessarily have to remember how big it
is, because it won't necessarily need that information to release
it. For example, if automatic arrays are allocated by
decrementing the stack pointer, as they often are on x86, then
they are usually freed along with the rest of the automatic
variables for the block or the function in a single lump, with no
separate per-variable or per-array accounting.

The Standard doesn't distinguish between compile time and
runtime, so perhaps this is all nonsense from the Standard's
point of view.

My point is simply this: that the programmer can use sizeof to find the size
of the array at any point in the scope, and the compiler has to be able to
respond to that with the correct size. It can't say "sorry, I've discarded
that information".

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[David T. Ashley]

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

David T. Ashley a écrit :

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

The array-handling is not a weakness. (It is only a weakness if you
can't write correct code.)

"Correct" meaning to you that all size information is discarded by the
compiler by default and must be passed again and again as a separate
argument with multiple occasions for errors.

Correct means that

int fn(int array[40])
{
// Here sizeof(array) is equal to a sizeof pointer
}

This *coould* be justified in a PDP-11, but it is surely no longer
justified today with machines 10 000 or more faster than a PDP-11.

>Array bounds checking carries with it the need for additional run-time
code, and penalizes execution time.

Obviously random memory overwrites are much faster.

The example you provided isn't representative.

Let's try:

int array[40];
....
printf("%d\n", (int)(sizeof(array)/sizeof(array[0])));

and I'll bet you get 40.

: )

The joy of 'C' is that it gives you the flexibility to choose (to carry) or
(not to carry) dimensioning information around. In some contexts (such as
certain \0-terminated strings) it isn't necessary to carry it. In other
contexts (numerical algorithms that operate on variable-size arrays, or
binary strings), it is necessary to carry the information around.

If you choose to carry the information around, because 'C' compiles so well,
there really is no performance penalty over what would have been in place if
the feature were "built-in" to the language.

The point is ... choice. You can do it as you want ... efficiently in
either case.

>That isn't right in every application. 'C' compiles quite well precisely
because it omits this kind of overhead.

Who wants it in every application? It could be optional, as is in
Pascal.

It is optional. It is just optional in a different sense than you'd like to
see.

>The pointer and array handling in 'C' is usable, but still maps quite
well to the underlying machine.

Sorry can't parse that sentence.

PARSE ERROR :-)

In 'C', the brackets ( [ ] ) are simply an operator. This maps quite well
to processor addressing modes (indexed offsets and so on). Compilers can do
quite a good job. The authors got it right, in terms of providing the right
amount of array functionality. It is rich enough to do anything you need to
do, but lean enough that the compiler can still do a good job.

The interchangeability of arrays and pointers is pure genius (it maps very
well to machine instruction sets).

The handling of multi-dimensional arrays in 'C' is pure genius. It was a
good call to realize that (with [i][j][k], for example), the compiler only
needs to know about the dimensioning of k in order to operate using j (i has
nothing to do with it).

Absolute genius.

>The original authors got it right.

The second-guessers 40 years after the fact still aren't getting it.

Yes of course. MY C, RIGHT OR WRONG...

40 years later the language needs evolving and accepting the fact that
an operation or a data structure that was OK for THAT time doesn't fit
into today's machines with vastly more ressources than in those
times.

This conservative attitude ah so popular in this group leads to the
demise of the language.

I don't immediately dismiss the possibility that I could be prejudiced or
closed-minded. This is absolutely possible.

But the points you tried to make ... there are very rational arguments
against them.

There are improvements that could be made to 'C' and to the preprocessor ...
just not the ones YOU believe would be improvements.

I think the key issue is that you don't understand the technical issues well
enough to understand the WHY of the language. The authors got 90% of it
right. But you're identifying the wrong 10%.

The treatment of arrays is ... just fine.

--
David T. Ashley (dt*@e3ft.com)
http://www.e3ft.com (Consulting Home Page)
http://www.dtashley.com (Personal Home Page)
http://gpl.e3ft.com (GPL Publications and Projects)

[jacob navia]

kyle york wrote:

Greetings,

jacob navia wrote:

>>
"Correct" meaning to you that all size information is discarded by the
compiler by default and must be passed again and again as a separate
argument with multiple occasions for errors.

Correct means that

int fn(int array[40])
{
// Here sizeof(array) is equal to a sizeof pointer
}

This *coould* be justified in a PDP-11, but it is surely no longer
justified today with machines 10 000 or more faster than a PDP-11.

Can you say embedded? You know, processors with 1 - 8K ROM and maybe a
couple of hundred bytes of RAM.

>>

>>Array bounds checking carries with it the need for additional
run-time code, and penalizes execution time.

Obviously random memory overwrites are much faster.

Only if you're incapable of writing correct code.

I am not the only one as it seems:
NASA Decides That A Software Error Doomed The Mars Global Surveyor
Spacecraft

Keith Cowing
Wednesday, January 10, 2007

During a meeting of the Mars Exploration Program Analysis Group Meeting
in Washington Dc, yesterday, NASA's John McNamee, Mars Exploration
Program addressed the issue of the recent failure of the Mars Global
Surveyor (MGS) spacecraft.

Apparently incorrect software doomed the spacecraft.

MGS stopped operating shortly after celebrating its tenth anniversary.

According to public comments made by McNamee: "We think that the failure
was due to a software load we sent up in June of last year. This
software tried to synch up two flight processors. Two addresses were
incorrect - two memory addresses were over written. As the geometry
evolved, we drove the [solar] arrays against a hard stop and the
spacecraft went into safe mode. The radiator for the battery pointed at
the sun, the temperature went up, and battery failed."

Yes, I can say "embedded" and I can even say MEMORY OVERWRITES ARE
FATAL!!!!

But of course, they are faster :-)

[Ian Collins]

Chris Torek wrote:

>
Note that the duration of VLAs is well-controlled and interacts
"correctly" with other block-scope variables:

for (int i = k; i < max; i += step) {
double a, b, tmp[i];
...
if (finished)
break;
...
}

but this is not true for alloca() space:

for (int i = k; i < max; i++) {
double a, b, *tmp;

tmp = alloca(i * sizeof *tmp);
...
if (finished)
break;
...
/* tmp is too small, we should get rid of it here */
/* unalloca(tmp); -- there is no way to do this */
}

While it is possible to come up with cases where "function duration"
objects -- what alloca() produces, if it works at all -- are useful,
this seems to be considerably rarer than normal automatic-duration
(block scope automatic) variables.

Thanks Chris for one of those "ah" moments when ones preconceived
notions about something are upended!

--
Ian Collins.

[Ben Bacarisse]

Kenneth Brody <ke******@spamcop.netwrites:

Ben Bacarisse wrote:

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

"C draws criticism because its standard explicitly identifies numerous cases
of undefined behavior, including some where the behavior could have been
made well defined, and does not specify any run-time error handling
mechanism." - the behaviour can *always* be made well-defined, but to do so
unnecessarily limits optimisation potential and *prevents* the provision of
third-party libraries. A language where everything is nailed down is an
unextensible language.

I think you are sightly overstating this case. If the standard
changed feature X from "undefined behaviour" to "implementation
defined" I can't see that this would hinder (you say *prevents*) any
third party library. I agree with the last point, but nailing
everything down is not the only alternative to UB.

[...]

The problem with changing all of the "undefined behavior" items in
the standard to "implementation defined" is that you have now placed
a great burden on the implementor to actually define the behavior.

This is quite correct and exactly why I think RH was rather
over-egging the pudding. To ague against there being rather too
liberal use of UB by explaining why removing *all* of it is a bad idea
is not a strong argument. I certainly would never argue for there to
be no UB -- the burden on the implementation would be excessive.

Consider the simple case of modifying something more than once
between sequence points. While it may be easy to define "i=i++;",
consider how many different ways this particular UB can be invoked.
Do you really want to have to define exactly what will happen, and
make sure that the same things happen regardless of optimization?

No. I did not argue for that. The sequence point rules seem to
strike an excellent balance between programmer convenience and
implementation freedom.

By arguing for any reduction in UB, I may seem like one of those who
want C to evolve into Java, but I don't. In fact, I can think of only
two cases if UB that I don't like: %d input formats and integer
overflow. I posted only because I thought that saying "you can't
define everything" was missing the point.

--
Ben.

[Mark McIntyre]

On 18 Jan 2007 21:41:55 -0800, in comp.lang.c , "Zach"
<ne****@gmail.comwrote:

>Can someone give a detailed rejoinder to this. Would also be nice if
someone updates the wiki page so that readers get the other perspective
and don't get the wrong impression about C:

http://en.wikipedia.org/wiki/Critici...mming_language

Amusing article. Many of the 'weaknesses' and 'lacks' of C are IMHO
actually benefits which keep the language lean and portable.

Much of the "justification" given for these being weaknesses relies on
either an assumption that another language is superior, or upon stuff
that was true 20 years ago (such as the #include model slowing down
compilation - come on, I've not had a problem with that since oh, the
nineties). The argument based upon design decisions taken by the C++
developers was humorous. Essentially "C is bad because we had to copy
it..."

I've amended it mildly, to try to point ouf that the viewpoint
presented in the article is highly subjective and disputed by many
experienced programmers. I expect my amendments to be removed by
someone fairly switfly. But thats no loss - Wikipedia is useless for
anything requiring objectivity.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Mark McIntyre]

On Fri, 19 Jan 2007 13:20:50 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>
I think that that page provides useful information to the reader.

I agree it could have done, had it not been quite so pejoratively
written in some places. Still, its more balanced than some.

>I disagree that we need closures, or similar constructs, but this
is a matter of opinion. The writer has a different opinion.

The whole thing is a matter of opinion. I disagree with about 80% of
what the writer thinks are "weaknesses" and the writer also seems to
have little experience in actually programming in C.

>The critic about arrays handling in C (one of the weakness of the
language) is perfectly valid.

This is one of the ones I disagree with. Or at least, if you insist on
this being a weakness of C, I insist on classes being a weakness of
C++, and the lack of pointers a weakness in Java, and ....
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Mark McIntyre]

On Fri, 19 Jan 2007 21:13:49 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>>
Only if you're incapable of writing correct code.

I am not the only one as it seems:

So you agree, you're incapable of writing correct code.... :-)

>NASA Decides That A Software Error Doomed The Mars Global Surveyor
Spacecraft

Sure, and did they mention C?

>According to public comments made by McNamee: "We think that the failure
was due to a software load we sent up in June of last year. This
software tried to synch up two flight processors. Two addresses were
incorrect - two memory addresses were over written.

Yes, I can say "embedded" and I can even say MEMORY OVERWRITES ARE
FATAL!!!!

Everyone knows this, shouting it won't make it any truer.

>But of course, they are faster :-)

So what has this to do with C?
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[jacob navia]

Mark McIntyre wrote:

So what has this to do with C?

Read the whole thread McIntyre. We were discussing
the advantages or disadvantages of bounds checking.

As you may (possibly) know, the consequence of writing
into an array out of bounds are memory overwrites.

The proponents of

"no bounds checking we are all real men"

say that bounds checking would "slow down" programs.

My argument is that any writing outside the bounds of
an array is 100% fatal and that specially in embedded
software defensive programming is necessary.

This kind of arguments are too much for you as it seems
since your message (as most of your posts actually)
just contains polemic. You did not address anything discussed
previously but sure, you make some sarcastic remarks
without any content at all.

Con you bring some arguments into the discussion?

Or that is beyond you?

jacob

[jacob navia]

Mark McIntyre wrote:

On Fri, 19 Jan 2007 13:20:50 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>>I think that that page provides useful information to the reader.

I agree it could have done, had it not been quite so pejoratively
written in some places. Still, its more balanced than some.

>>I disagree that we need closures, or similar constructs, but this
is a matter of opinion. The writer has a different opinion.

The whole thing is a matter of opinion. I disagree with about 80% of
what the writer thinks are "weaknesses" and the writer also seems to
have little experience in actually programming in C.

>>The critic about arrays handling in C (one of the weakness of the
language) is perfectly valid.

This is one of the ones I disagree with. Or at least, if you insist on
this being a weakness of C, I insist on classes being a weakness of
C++, and the lack of pointers a weakness in Java, and ....

I cite from the wikipedia article:

<<
Although C supports static arrays, it is not required that array indices
be validated (bounds checking). For example, one can write to the sixth
element of an array with five elements, yielding generally undesirable
results.

>>

You disagree with that? You think that making array bounds checking
automatic would be bad or wouldn't improve the safety of the
language?

[Richard Tobin]

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

><<
Although C supports static arrays, it is not required that array indices
be validated (bounds checking). For example, one can write to the sixth
element of an array with five elements, yielding generally undesirable
results.

>

What has staticness got to do with this?

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Cesar Rabak]

Mark McIntyre escreveu:

On Fri, 19 Jan 2007 21:13:49 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>>Only if you're incapable of writing correct code.

I am not the only one as it seems:

So you agree, you're incapable of writing correct code.... :-)

>NASA Decides That A Software Error Doomed The Mars Global Surveyor
Spacecraft

Sure, and did they mention C?

NO, but it is public domain:
http://mpfwww.jpl.nasa.gov/MPF/mpf/faqs_general.html

Specially this part:

"The code was developed using VxWorks as the real-time OS and "C" and
assembly languages."

[jacob navia]

Richard Tobin wrote:

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

>><<
Although C supports static arrays, it is not required that array indices
be validated (bounds checking). For example, one can write to the sixth
element of an array with five elements, yielding generally undesirable
results.

What has staticness got to do with this?

-- Richard

Nothing, it is a bug in that article.

As you may know, bugs are not only to be found in C

:-)

But the rest is correct. There is no way in C to make
a bounds checked array. That led me to operator overloading
to have resizable arrays and bound checked arrays
using the '[' and ']' operator. I think this would allow
array bound checking without disturbing anything else
in the language.

Since this would be user defined, it would be much better
since they would be absolutely OPTIONAL.

You would use them whenever you think that an overflow could happen.

[Ian Collins]

jacob navia wrote:

>
The proponents of

"no bounds checking we are all real men"

say that bounds checking would "slow down" programs.

My argument is that any writing outside the bounds of
an array is 100% fatal and that specially in embedded
software defensive programming is necessary.

The gripe is probably more with the cost enforced bounds checking
(Pascal?) than the concept its self.

There are other means to achieve the same end, mainly in the form of
external tools than can be used to either statically detect (difficult)
or run-time check code. I always check my embedded code in a hosted
simulation environment as well as extensive unit test and apply all the
access checking tools at my disposal during this testing.

<OT>The C++ standard library vector class provides a bounds checked
access member along with the array subscript operator, but I've yet to
see it used in production code. So programmers either aren't aware of
it, or don't think they can afford the cost. If the same were offered
in C, I sure the take up would be similar.<OT>

--
Ian Collins.

[kyle york]

Greetings,

jacob navia wrote:

>
The proponents of

"no bounds checking we are all real men"

I doubt anyone is even implying this.

>
say that bounds checking would "slow down" programs.

Or, more importantly might cause one to drop C (look back, you'll see
the environment about which I speak) and rewrite in assembly which, in
my experience, is far more error prone. Suddenly an operation that
should take two or three instructions takes a dozen or more.

>
My argument is that any writing outside the bounds of
an array is 100% fatal and that specially in embedded
software defensive programming is necessary.

The ``is 100% fatal'' is completely false, the defensive programming is
necessary is a big, ``Duh!'' There are numerous cases where writing out
of the bounds of the array is innocuous, or at worst will cause the
program to simply fail.

Just out of curiosity, let's say array bounding is added to the
language, that would necessitate adding execption handling also, yes? If
you're just going to crash the program you've not added much and I
believe exception handling is discussed down the hall, to your right, in
C++ land.
--
Kyle A. York
Sr. Subordinate Grunt

[jacob navia]

kyle york wrote:

Greetings,

jacob navia wrote:

>>
The proponents of

"no bounds checking we are all real men"

I doubt anyone is even implying this.

>>
say that bounds checking would "slow down" programs.

Or, more importantly might cause one to drop C (look back, you'll see
the environment about which I speak) and rewrite in assembly which, in
my experience, is far more error prone. Suddenly an operation that
should take two or three instructions takes a dozen or more.

>>
My argument is that any writing outside the bounds of
an array is 100% fatal and that specially in embedded
software defensive programming is necessary.

The next sentence needs to be framed for posterity kyle:

-------------------------------------------------------------------------

>
The ``is 100% fatal'' is completely false, the defensive programming is
necessary is a big, ``Duh!'' There are numerous cases where writing out
of the bounds of the array is innocuous, or at worst will cause the
program to simply fail.

--------------------------------------------------------------------------

GREAT!!!

OF COURSE. You are always lucky, anyway, programming in C must be fast.
Yes; I see your pilosophy. "Most of the time I overwrite nothing
important so... who cares?"

Just out of curiosity, let's say array bounding is added to the
language, that would necessitate adding execption handling also, yes?

No. As I said in my message, if you overload the '[' operator, it is
YOU that defines what action should be taken when an array index out of
bounds exception happens:

1) You can send a signal and use that mechanism.
2) You can longjmp to a recovery point.
3) You can just log it and ignore it. This is very risky
since you are ignoring an error. It is better than silently
corrupting memory though.

If
you're just going to crash the program you've not added much

What?

You can then during the test phase catch a lot of silent errors!!!!!
that are VERY difficult to find or invisible if the program doesn't
destroy vital data.

[jacob navia]

Ian Collins wrote:

jacob navia wrote:

>>The proponents of

"no bounds checking we are all real men"

say that bounds checking would "slow down" programs.

My argument is that any writing outside the bounds of
an array is 100% fatal and that specially in embedded
software defensive programming is necessary.

The gripe is probably more with the cost enforced bounds checking
(Pascal?) than the concept its self.

There are other means to achieve the same end, mainly in the form of
external tools than can be used to either statically detect (difficult)
or run-time check code. I always check my embedded code in a hosted
simulation environment as well as extensive unit test and apply all the
access checking tools at my disposal during this testing.

This is very good but bound checked arrays would allow this tests
to be done faster and for more people.

<OT>The C++ standard library vector class provides a bounds checked
access member along with the array subscript operator, but I've yet to
see it used in production code. So programmers either aren't aware of
it, or don't think they can afford the cost. If the same were offered
in C, I sure the take up would be similar.<OT>

Maybe because they have to change the [ ] access to a function call
or something different?

How do you access a bound checked array? With [ ] or not?

jacob

[Ben Pfaff]

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

But the rest is correct. There is no way in C to make
a bounds checked array. That led me to operator overloading
to have resizable arrays and bound checked arrays
using the '[' and ']' operator. I think this would allow
array bound checking without disturbing anything else
in the language.

There is already one popular, widely supported language with
C-like syntax that supports operator overloading and can thus
support bound checked arrays in the same fashion. So why do we
need it in C, too?
--
Ben Pfaff
bl*@cs.stanford.edu
http://benpfaff.org

[Cesar Rabak]

kyle york escreveu:

Greetings,

jacob navia wrote:

[snipped]

>My argument is that any writing outside the bounds of
an array is 100% fatal and that specially in embedded
software defensive programming is necessary.

The ``is 100% fatal'' is completely false, the defensive programming is
necessary is a big, ``Duh!'' There are numerous cases where writing out
of the bounds of the array is innocuous, or at worst will cause the
program to simply fail.

Interesting approach! I think there's a company in Redmond that probably
has a poster in some wall with this mantra!

>
Just out of curiosity, let's say array bounding is added to the
language, that would necessitate adding execption handling also, yes?

Yes. Would you dispute that even if the system was shut off to a safe
state and a means of detecting it is better than the random errors that
normally ensues?

[jacob navia]

Ben Pfaff wrote:

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

>>But the rest is correct. There is no way in C to make
a bounds checked array. That led me to operator overloading
to have resizable arrays and bound checked arrays
using the '[' and ']' operator. I think this would allow
array bound checking without disturbing anything else
in the language.

There is already one popular, widely supported language with
C-like syntax that supports operator overloading and can thus
support bound checked arrays in the same fashion. So why do we
need it in C, too?

Wrong. There are far MORE languages than C++. Fortran accepts
operator overloading. Yes Fortran.

And Visual Basic, and many others!

This is quite common technology today.

[jacob navia]

Cesar Rabak wrote:

Mark McIntyre escreveu:

>On Fri, 19 Jan 2007 21:13:49 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>>>Only if you're incapable of writing correct code.

I am not the only one as it seems:

So you agree, you're incapable of writing correct code.... :-)

>>NASA Decides That A Software Error Doomed The Mars Global Surveyor
Spacecraft

Sure, and did they mention C?

NO, but it is public domain:
http://mpfwww.jpl.nasa.gov/MPF/mpf/faqs_general.html

Specially this part:

"The code was developed using VxWorks as the real-time OS and "C" and
assembly languages."

As described in the post mortem analysis, the bug was uploaded in July,
but manifested itself in November...

That means that all tests that were shorter than 4 months did not see
this bug. The big problem with no bounds checking is that the
consequences are so hard to detect without language support.

jacob

[Ian Collins]

jacob navia wrote:

>

><OT>The C++ standard library vector class provides a bounds checked
access member along with the array subscript operator, but I've yet to
see it used in production code. So programmers either aren't aware of
it, or don't think they can afford the cost. If the same were offered
in C, I sure the take up would be similar.<OT>

Maybe because they have to change the [ ] access to a function call
or something different?

How do you access a bound checked array? With [ ] or not?

In the case of C++, array.at().

--
Ian Collins.

[Ben Pfaff]

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

Ben Pfaff wrote:

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

>>>But the rest is correct. There is no way in C to make
a bounds checked array. That led me to operator overloading
to have resizable arrays and bound checked arrays
using the '[' and ']' operator. I think this would allow
array bound checking without disturbing anything else
in the language.

There is already one popular, widely supported language with
C-like syntax that supports operator overloading and can thus
support bound checked arrays in the same fashion. So why do we
need it in C, too?

Wrong. There are far MORE languages than C++. Fortran accepts
operator overloading. Yes Fortran.

And Visual Basic, and many others!

I don't think that Fortran or Visual Basic has C-like syntax, nor
do I see how they're relevant to a proposal to add operator
overloading to C.
--
"The lusers I know are so clueless, that if they were dipped in clue
musk and dropped in the middle of pack of horny clues, on clue prom
night during clue happy hour, they still couldn't get a clue."
--Michael Girdwood, in the monastery

[jacob navia]

Ian Collins wrote:

jacob navia wrote:

>>><OT>The C++ standard library vector class provides a bounds checked
access member along with the array subscript operator, but I've yet to
see it used in production code. So programmers either aren't aware of
it, or don't think they can afford the cost. If the same were offered
in C, I sure the take up would be similar.<OT>

Maybe because they have to change the [ ] access to a function call
or something different?

How do you access a bound checked array? With [ ] or not?

In the case of C++, array.at().

Well, that explains everything. It is just that people would have to
change all array accesses to an incompatible syntax to use that.

That's why I consider the operator overloading solution better, since
allows you with editing just the declaration to change all array
accesses to bound checked or not!

[Yevgen Muntyan]

jacob navia wrote:

Ian Collins wrote:

>jacob navia wrote:

>>><OT>The C++ standard library vector class provides a bounds checked
access member along with the array subscript operator, but I've yet to
see it used in production code. So programmers either aren't aware of
it, or don't think they can afford the cost. If the same were offered
in C, I sure the take up would be similar.<OT>

Maybe because they have to change the [ ] access to a function call
or something different?

How do you access a bound checked array? With [ ] or not?

In the case of C++, array.at().

Well, that explains everything. It is just that people would have to
change all array accesses to an incompatible syntax to use that.

That's why I consider the operator overloading solution better, since
allows you with editing just the declaration to change all array
accesses to bound checked or not!

You mean C++ folks should consider operator overloading so their
std::vector usage can be made safer?

Regards,
Yevgen

[Keith Thompson]

ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:

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

<<
Although C supports static arrays, it is not required that array indices
be validated (bounds checking). For example, one can write to the sixth
element of an array with five elements, yielding generally undesirable
results.

>>

What has staticness got to do with this?

I suspect the article isn't using the word "static" in the way the C
standard uses it. It probably just means that the size is a
compile-time constant (some other languages use the term "static" in
that sense). (This ignores VLAs.)

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

[Ian Collins]

jacob navia wrote:

Ian Collins wrote:

>jacob navia wrote:

>>><OT>The C++ standard library vector class provides a bounds checked
access member along with the array subscript operator, but I've yet to
see it used in production code. So programmers either aren't aware of
it, or don't think they can afford the cost. If the same were offered
in C, I sure the take up would be similar.<OT>

Maybe because they have to change the [ ] access to a function call
or something different?

How do you access a bound checked array? With [ ] or not?

In the case of C++, array.at().

Well, that explains everything. It is just that people would have to
change all array accesses to an incompatible syntax to use that.

It does explain a lot.

That's why I consider the operator overloading solution better, since
allows you with editing just the declaration to change all array
accesses to bound checked or not!

You still hit the fundamental problem that C arrays are not objects, so
you can't bind overloaded operators to them. I'm afraid you are pissing
in the wind if you try to get either of these features added to C. They
exist elsewhere, so if you want them, you have to go there.

The same problem exists in C++ and that's one reason why 'array objects'
tend to be preferred over 'naked' arrays in contemporary C++.

--
Ian Collins.