Criticisms?
Zach
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/Criticism_of_the_C_programming_language
Zach
user923005
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
news:1169185315.0...@a75g2000cwd.googlegroups.com...
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 (d...@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
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
>
> "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.
>
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
> 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".
user923005
I guess it is because not all computers have a stack.
Chris Torek
>>"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 <51ba87F1...@mid.individual.net>
Ian Collins <ian-...@hotmail.com> wrote:
>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) +1 801 277 2603
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
David T. Ashley <d...@e3ft.com> wrote:
>"Zach" <net...@gmail.com> wrote in message
>news:1169185315.0...@a75g2000cwd.googlegroups.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/Criticism_of_the_C_programming_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
> "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", °rees_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
> Richard Heathfield <r...@see.sig.invalid> writes:
>
>> "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", °rees_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.
jacob navia
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
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", °rees_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
<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.
mark_b...@pobox.com
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
news:1t-dnQH6tf8...@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/Criticism_of_the_C_programming_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
news:45b0b7a3$0$25913$ba4a...@news.orange.fr...
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.
jacob navia
> "jacob navia" <ja...@jacob.remcomp.fr> wrote in message
> news:45b0b7a3$0$25913$ba4a...@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/Criticism_of_the_C_programming_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
>
> Richard Heathfield <r...@see.sig.invalid> writes:
>
> > "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:ThisIsA...@gmail.com>
Keith Thompson
[...]
> 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
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
> David T. Ashley a écrit :
>> "jacob navia" <ja...@jacob.remcomp.fr> wrote in message
>> news:45b0b7a3$0$25913$ba4a...@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?
Ben Pfaff
> 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[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz.\
\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
> Richard Heathfield <r...@see.sig.invalid> writes:
>
>> 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".
David T. Ashley
> David T. Ashley a écrit :
>> "jacob navia" <ja...@jacob.remcomp.fr> wrote in message
>> news:45b0b7a3$0$25913$ba4a...@news.orange.fr...
>>
>> 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.
jacob navia
> 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
>
> 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
> Ben Bacarisse wrote:
>>
>> Richard Heathfield <r...@see.sig.invalid> writes:
>>
>> > "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
<net...@gmail.com> 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/Criticism_of_the_C_programming_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
<ja...@jacob.remcomp.fr> wrote:
>
> 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
<ja...@jacob.remcomp.fr> wrote:
>>
>> 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?
jacob navia
> 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
> On Fri, 19 Jan 2007 13:20:50 +0100, in comp.lang.c , jacob navia
> <ja...@jacob.remcomp.fr> wrote:
>
>
>>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
jacob navia <ja...@jacob.remcomp.fr> wrote:
><<
>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
> On Fri, 19 Jan 2007 21:13:49 +0100, in comp.lang.c , jacob navia
> <ja...@jacob.remcomp.fr> wrote:
>
>>> 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
> In article <45b15495$0$27395$ba4a...@news.orange.fr>,
> jacob navia <ja...@jacob.remcomp.fr> wrote:
>
>
>><<
>>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
>
> 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.
>
(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
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.
jacob navia
> 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.
>
--------------------------------------------------------------------------
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
> 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
> 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
b...@cs.stanford.edu
http://benpfaff.org
Cesar Rabak
> 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
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
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
>
>> <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?
>
--
Ian Collins.
Ben Pfaff
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
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
You mean C++ folks should consider operator overloading so their
std::vector usage can be made safer?
Regards,
Yevgen
Keith Thompson
> In article <45b15495$0$27395$ba4a...@news.orange.fr>,
> jacob navia <ja...@jacob.remcomp.fr> wrote:
>
> ><<
> >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
> 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 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.
CBFalconer
>
... snip ...
>
> 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.
All you have to do, in C, is every time you write a routine that
receives an array that it will modify (i.e. non const) you ensure
that the size of that array is also an input parameter. Then you
can apply checks in the routine, as and if needed. Almost anyone
can do it.
Usually something like "if (x < max) *a[x++] = ch;" suffices.
Try it, you might like it.
--
"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
Keith Thompson
[...]
> 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.
Yes, C arrays are objects. See the definition of the word "object" in
the C standard. <OT>The C++ standard's definition is similar.</OT>
The reason you can't bind overloaded operators to C arrays is that C
doesn't support operator overloading.
artifa...@googlemail.com
> All you have to do, in C, is every time you write a routine that
> receives an array that it will modify (i.e. non const) you ensure
> that the size of that array is also an input parameter. Then you
> can apply checks in the routine, as and if needed. Almost anyone
> can do it.
>
I like the approach taken by djb, amongst others.
struct array {
void *x; /* raw array data */
unsigned int es; /* element size */
unsigned long u; /* number of used elements */
unsigned long a; /* number of allocated elements */
};
Operations are:
int array_concat(struct array *, void *);
int array_insert(struct array *, void *, unsigned long);
etc.
Relieves the burden of keeping track of array sizes and all functions
could be easily inlined. The nice feature about this particular
arrangement
is that the raw data is available in the .x member, as if you'd just
said:
struct object o[128];
..or whatever. It means that it plays well with external libraries as
they don't need to have any knowledge of the array structure. A library
requiring an array of int, for example, could just be passed the .x
member of a correctly initialized array.
MC
santosh
> > 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
Just curious, but does your newsreader randomly select a sig for you,
or do you manually do so, each time you post?
Zach
Zach
Ben Pfaff
> Just curious, but does your newsreader randomly select a sig for you,
> or do you manually do so, each time you post?
It's random.
--
"Programmers have the right to be ignorant of many details of your code
and still make reasonable changes."
--Kernighan and Plauger, _Software Tools_
Malcolm McLean
"Ian Collins" <ian-...@hotmail.com> 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>
>
arrays of integers.
Join my campaign for 64-bit ints. We need one representation of data in the
machine.
Malcolm McLean
"Zach" <net...@gmail.com> wrote in message
> 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/Criticism_of_the_C_programming_language
>
There are three sorts of criticism
1) Criticism of the concept - Lotus cars are a bad idea because I don't like
fast cars.
2) Criticism of mistakes - a Lotus has the handbrake on the wrong side
3) Criticism of an inherent weakness - A Lotus will only carry two people.
Class 3) isn't really valid. A car with four passengers inherently travels
slower than one with only two, and the makers can't abolish the law of
conservation of energy.
Class 1) is valid but really raises a lot of very deep questions, about the
sort of society we want to create and so forth.
Class 2) You can always make some criticisms. The case of the C, the use of
char for bytes, and the 2d array notation, spring to mind as major mistakes.
Zach
>
> Class 2) You can always make some criticisms. The case of the C, the use of
> char for bytes, and the 2d array notation, spring to mind as major mistakes.
Can you elaborate on why these are, in your view, mistakes?
Zach
Richard Heathfield
> "santosh" <santo...@gmail.com> writes:
>
>> Just curious, but does your newsreader randomly select a sig for you,
>> or do you manually do so, each time you post?
>
> It's random.
I believe you, Ben. :-)
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Malcolm McLean
representing something in a natuiral language, should fit into a byte, the
smallest addressible unit of memory.
For other reasons it is conveninet to have 8-bit bytes, which means that
everything is fine in English, but a nuisance if you wnat to support other
languages.
2d arrays are difficult. Try writing a function that accepts a greyscale
image as a parameter and sets it to white.
If you think that was unfair, try writing the the same function when you
know the image width at compile-time.
This is purely a notational inconvenience. No violence is needed to the
language to make 2d arrays usable.
santosh
> "Zach" <net...@gmail.com> wrote in message
> > 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/Criticism_of_the_C_programming_language
> >
> There are three sorts of criticism
> 1) Criticism of the concept - Lotus cars are a bad idea because I don't like
> fast cars.
> 2) Criticism of mistakes - a Lotus has the handbrake on the wrong side
> 3) Criticism of an inherent weakness - A Lotus will only carry two people.
> Class 2) You can always make some criticisms. The case of the C, the use of
> char for bytes, and the 2d array notation, spring to mind as major mistakes.
IMHO const and static are closer to being a mistake than anything else.
Even then I wouldn't call them a mistake. The creators of C didn't have
the advantage of hindsight, and even if they had had it, they're still
human and prone to biases.
Malcolm McLean
"kyle york" <ky...@cisco.com> wrote in
>
> 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.
>
Say I am writing an automatic drug-dispenser. Every ten minutes of so we add
the right dose of drug to the patient's drip.
Scenario 1: we overwrite the wrong memory. The dispenser releases the wrong
dose.
Scenario2: we overwrite the wrong memory. The program exits with an error
message.
2) is no different to a fuse going or the power being turned off, and the
hospital ought to be able to cope. 1) is much more dangerous.
jacob navia
Besides, instead of just exit() you can have OTHER exit
strategies like lonjmp to a restart point, for instance
CBFalconer
So you wrote the application in the wrong language. You know how
careless you are, and you should have used Pascal or Ada. The
fault is yours, not the C language.
--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
Cesar Rabak
> Malcolm McLean wrote:
>> "kyle york" <ky...@cisco.com> wrote in
>>> 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.
>> Yes you have.
>> Say I am writing an automatic drug-dispenser. Every ten minutes
>> of so we add the right dose of drug to the patient's drip.
>>
>> Scenario 1: we overwrite the wrong memory. The dispenser releases
>> the wrong dose.
>> Scenario2: we overwrite the wrong memory. The program exits with
>> an error message.
>>
>> 2) is no different to a fuse going or the power being turned off,
>> and the hospital ought to be able to cope. 1) is much more dangerous.
>
> So you wrote the application in the wrong language. You know how
> careless you are, and you should have used Pascal or Ada. The
> fault is yours, not the C language.
>
there are applications which should not be written in C? Or perhaps this
problem of overwriting memory without warning is amenable in certain
circumstances and others not?
Richard Heathfield
> CBFalconer escreveu:
>>
>> So you wrote the application in the wrong language. You know how
>> careless you are, and you should have used Pascal or Ada. The
>> fault is yours, not the C language.
>>
> This is an interesting comment: this reasoning brings to the table that
> there are applications which should not be written in C?
You missed the important words: "You know how careless you are".
Frankly, if you're a careful programmer, it doesn't really matter what
language you choose (partly because you'll choose carefully and partly
because you'll use it carefully).
For careful programmers, C is a fine choice. (There are, of course, other
fine choices too.)
And if you're a careless programmer, no language (that is sufficiently
powerful to Get The Job Done) is likely to be able to protect you from your
carelessness. One way or another, you'll get bitten in the end.
jacob navia
>
> So you wrote the application in the wrong language. You know how
> careless you are, and you should have used Pascal or Ada. The
> fault is yours, not the C language.
>
C is for "real men" eh Chuck?
C'mon. You never make mistakes?
The language should do this checking automatically for you. That's all
we are proposing.
jacob
Cesar Rabak
> Cesar Rabak said:
>
>> CBFalconer escreveu:
>>> So you wrote the application in the wrong language. You know how
>>> careless you are, and you should have used Pascal or Ada. The
>>> fault is yours, not the C language.
>>>
>> This is an interesting comment: this reasoning brings to the table that
>> there are applications which should not be written in C?
>
> You missed the important words: "You know how careless you are".
>
> Frankly, if you're a careful programmer, it doesn't really matter what
> language you choose (partly because you'll choose carefully and partly
> because you'll use it carefully).
In fact, I did not 'miss', but let's put in business context: if we
agree that for writing a certain piece of software in C it is required
more attention, care, <you name it> which ultimately equates to more
work, then we have an issue on the choice of the language (or more
exactly speaking its underlying technology and philosophy).
>
> For careful programmers, C is a fine choice. (There are, of course, other
> fine choices too.)
I agree with you. I only maintain that this carefulness come at a price
of more lengthy development. Perhaps, if the language does not evolve,
at another price of newcomers running in the same errors over and over.
>
> And if you're a careless programmer, no language (that is sufficiently
> powerful to Get The Job Done) is likely to be able to protect you from your
> carelessness. One way or another, you'll get bitten in the end.
>
Again a point which /in extremis/ I do not dispute. However, certain
languages, or features that could be added to C as discussed in this NG,
could reduce the space for certain errors which the present technology
can afford (more often than not we're speaking of some CPU cycles
overhead on the runtime and perhaps a slightly long compile time).
Regards,
--
Cesar Rabak
Richard Heathfield
> CBFalconer a écrit :
>>
>> So you wrote the application in the wrong language. You know how
>> careless you are, and you should have used Pascal or Ada. The
>> fault is yours, not the C language.
>>
>
> C is for "real men" eh Chuck?
C is for C programmers.
>
> C'mon. You never make mistakes?
For the Nth time, there is a difference between the claim "C is for careful
programmers" and the claim "C is for people who never make mistakes". They
are not the same claim. They are different claims. "Careful" doesn't mean
"never makes mistakes". Please understand this.
> The language should do this checking automatically for you. That's all
> we are proposing.
If you want a language like that, such languages already exist. If you want
that feature in C, libraries already exist which can supply it. There is no
need to change C itself.
jacob navia
Pure nonsense.
No arguments. C is the best thing since sliced bread, and if the
language has a bug it is not a bug, it is just that YOU are too
stupid to use it.
Heathfield, and others use the same "argument" over and over. The
language is flawless, it is just the stupid programmers. To hear
them, they never had a crash in their lives.
Of course, saying that here is easy.
jacob
Malcolm McLean
"Cesar Rabak" <csr...@yahoo.com.br> wrote in message
> This is an interesting comment: this reasoning brings to the table that
> there are applications which should not be written in C? Or perhaps this
> problem of overwriting memory without warning is amenable in certain
> circumstances and others not?
>
happen if the program misfunctions is that you spoil someone's enjoyment of
a game. If you are writing a medical application, the consequences of a bug
are much more serious.
So I'd pay 1000 dollars for a safe drug dispensing device rather than 100
dollars for a risky one, but I wouldn't pay 1000 dollars for a game that
never crashed versus 100 for one that crashed every two months.
Malcolm McLean
"santosh" <santo...@gmail.com> wrote in message
> IMHO const and static are closer to being a mistake than anything else.
> Even then I wouldn't call them a mistake. The creators of C didn't have
> the advantage of hindsight, and even if they had had it, they're still
> human and prone to biases.
>
think he was right - as an aid to documentation it is good, but as a
programming construct causes more problems than it solves.
jacob navia
I don't see your point. You mean C is just for writing games?
Cesar Rabak
automatic checking don't change C, change the language you program and
leave C as is.
In retrospect it seems to be a philosophy based on free market: let the
programmers (broadly encompassing all involved in implementing) decide!
Malcolm McLean
"David T. Ashley" <d...@e3ft.com> wrote in message
> 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).
>
No it isn't.
An image is a two-dimensional object if anything is.
However what good is an image algorithm that will only work on one size of
image? In practise, you need to pass the dimensions in at run-time. Which
means treating it as a 1d array and manually calculating the offset.
It would have been very easy to add some decent syntax to the language.
Ben Pfaff
> An image is a two-dimensional object if anything is.
> However what good is an image algorithm that will only work on one size of
> image? In practise, you need to pass the dimensions in at run-time. Which
> means treating it as a 1d array and manually calculating the offset.
> It would have been very easy to add some decent syntax to the language.
You're in luck: C99 has such syntax. Here's an example of its
use taken straight from the standard.
void addscalar(int n, int m,
double a[n][n*m+300], double x);
int main()
{
double b[4][308];
addscalar(4, 2, b, 2.17);
return 0;
}
void addscalar(int n, int m,
double a[n][n*m+300], double x)
{
for (int i = 0; i < n; i++)
for (int j = 0, k = n*m+300; j < k; j++)
// a is a pointer to a VLA with n*m+300 elements
a[i][j] += x;
}
--
"...Almost makes you wonder why Heisenberg didn't include postinc/dec operators
in the uncertainty principle. Which of course makes the above equivalent to
Schrodinger's pointer..."
--Anthony McDonald
Mark McIntyre
<ja...@jacob.remcomp.fr> wrote:
>Mark McIntyre wrote:
>> So what has this to do with C?
>
>Read the whole thread McIntyre.
I Read the whole thread. Stop trimming to remove context in the hope
that people will get confused, its rude, disingenuous and downright
unpleasant.
>We were discussing
>the advantages or disadvantages of bounds checking.
No, we were discussing a Wiki entry criticising C, and you brought in
a spurious example not even written in C.
>As you may (possibly) know, the consequence of writing
>into an array out of bounds are memory overwrites.
The fact that you can kill pedestrians by driving badly is not an
argument for banning cars, its an argument for banning you from
driving.
>My argument is that any writing outside the bounds of
>an array is 100% fatal
False, but we'll pass on.
>and that specially in embedded
>software defensive programming is necessary.
Sure. Its called "checking your bloody code properly".
>This kind of arguments are too much for you as it seems
>since your message (as most of your posts actually)
>just contains polemic.
Hello pot, meet kettle.
--
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
<ja...@jacob.remcomp.fr> wrote:
>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?
I do so love it when someone lovingly crafts a question so that any
answer other than the one they want would seem perverse. Weaselly of
course, but lovely.
Here's my answer, phrased similarly.
I agree that carelessly or cluelessly writing off the end of an array
is bad. I think that making array bounds checking facilities available
to help the clueless and careless from screwing up would be
beneficial, despite the indisputable performance penalty it incurs,
since code written by such people is unlikely to be of much use in
time-critical places anyway.
Luckily there are plenty of tools which do this, and in fact many
compilers come with it for free, especially in debug mode.
I therefore strongly disagree that it should be *compulsory*. Plenty
of languages offer such facilities already (consider C++ for instance,
which allows both models), so that if someone wants such compulsory
features, they can get 'em.
I myself take care when programming to avoid schoolboy errors. Anyone
who relies on his tools to cover for his own careless is a poor
programmer. Thats not to say my code can't crash due to array
overruns, but its an *extremely* uncommon occurence.
Mark McIntyre
<ja...@jacob.remcomp.fr> wrote:
>Ben Pfaff wrote:
>> 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.
Please clearly state which part of Ben's comment above is wrong.
Sheesh, and you complain about /me/ not reading threads properly.
Mark McIntyre
<ja...@jacob.remcomp.fr> wrote:
>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?"
Okay, its official. You're only interested in abusing people. Here's
what Kyle said:
Firstly he noted that you were stating the obvious with regard to
defensive programming
Secondly he noted that its false that _all_ memory overruns are fatal.
This is completely true, your hyperbole and other nonsense
notwithstanding. Consider a simple case - two adjacent arrays of 10
chars each. Overwriting the 1st char of the 2nd array by mistake will
be annoying maybe, confusing possibly. Fatal no.
>> 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:
In other words you add exception handling, yes?
>You can then during the test phase catch a lot of silent errors!!!!!
I can do this anyway. Since about 1995 my C compiler vendor has
chucked this facility in *for free* as part of the compiler suite.
Mark McIntyre
<csr...@yahoo.com.br> wrote:
> 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?
Depends entirely. If you have a big array of character arrays holding
say error messages, getting "onsufficient database storage space left"
instead of "insufficient" would hardly be fatal. Annoying, yes.
Mark McIntyre
<regn...@btinternet.com> wrote:
>Scenario 1: we overwrite the wrong memory. The dispenser releases the wrong
>dose.
>Scenario2: we overwrite the wrong memory. The program exits with an error
>message.
The point that others here are making is that these errors do not
happen randonly, they happen because you wrote the programme wrong.
Don't do that.
"Dad, it hurts when I hit my head with a hammer"
"Stop it then."
Mark McIntyre
<csr...@yahoo.com.br> wrote:
>In fact, I did not 'miss', but let's put in business context:
Okay, lets.
>if we
>agree that for writing a certain piece of software in C it is required
>more attention, care, <you name it> which ultimately equates to more
>work, then we have an issue on the choice of the language (or more
>exactly speaking its underlying technology and philosophy).
And of programmers. Moral: Don't write mission critical programmes
using fresh grads from law school who did Comp Sci in their spare
time.
Mark McIntyre
<ja...@jacob.remcomp.fr> wrote:
>Heathfield, and others use the same "argument" over and over. The
>language is flawless,
Richard, I and others have NEVER said that. You lie in your teeth.
>it is just the stupid programmers.
Sure, if programmers are stupid, expect junk code.
>To hear them, they never had a crash in their lives.
Again you lie in your teeth.
I give you the benefit of teh doubt, perhaps you simply don't want to
listen to anyone who disagrees with you and therefore prefer to make
up stories about them which please your ego. Either way, you're
completly wrong.
Mark McIntyre
<ja...@jacob.remcomp.fr> wrote:
>Malcolm McLean a écrit :
>
>> So I'd pay 1000 dollars for a safe drug dispensing device rather than 100
>> dollars for a risky one, but I wouldn't pay 1000 dollars for a game that
>> never crashed versus 100 for one that crashed every two months.
>
>I don't see your point. You mean C is just for writing games?
Idiot.
Cesar Rabak
> jacob navia said:
[snipped]
>> The language should do this checking automatically for you. That's all
>> we are proposing.
>
> If you want a language like that, such languages already exist. If you want
> that feature in C, libraries already exist which can supply it. There is no
> need to change C itself.
>
Yes. If a user (person or organization) more than is available via these
mechanisms, I think it is wise they look for another language.
Cesar Rabak
> Cesar Rabak a écrit :
>> CBFalconer escreveu:
>>> So you wrote the application in the wrong language. You know how
>>> careless you are, and you should have used Pascal or Ada. The
>>> fault is yours, not the C language.
>>>
>> This is an interesting comment: this reasoning brings to the table
>> that there are applications which should not be written in C? Or
>> perhaps this problem of overwriting memory without warning is amenable
>> in certain circumstances and others not?
>
> Pure nonsense.
I do not see any nonsense at all. Au contrarie, it is clear that
/languages/ do not make mistakes (they may have implementation bugs)
people do make the mistakes.
>
> No arguments. C is the best thing since sliced bread, and if the
> language has a bug it is not a bug, it is just that YOU are too
> stupid to use it.
Languages do not /have/ bugs they have specifications which you may like
or not.
Some languages may require more attention to avoid some trivially
avoidable mistakes in other languages.
The trade off, from which all this discussion comes is that some of them
are seem as reasonable or adequate and the advantages of a lesser safety
seen as advantages ('features').
>
> Heathfield, and others use the same "argument" over and over. The
> language is flawless, it is just the stupid programmers. To hear
> them, they never had a crash in their lives.
I have a different reading: they saying the decisions made for the
design of C are satisfactory for a huge community of developers and that
changing the language to add certain features which already exist in
other languages may be worth the effort or the head aches will ensue.
Joe Wright
scribe. Brian Kernighan is a fine and famous programmer in his own right
but he did not write C. He wrote about C.
--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Cesar Rabak
> "Cesar Rabak" <csr...@yahoo.com.br> wrote in message
>> This is an interesting comment: this reasoning brings to the table
>> that there are applications which should not be written in C? Or
>> perhaps this problem of overwriting memory without warning is
>> amenable in certain circumstances and others not?
>>
> Obviously if you are writing a video game the worst thing that is
> likely to happen if the program misfunctions is that you spoil
> someone's enjoyment of a game. If you are writing a medical
> application, the consequences of a bug are much more serious.
>
http://www.st.cs.uni-sb.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf
game developers are the first canvassing the industry for a more safe
language including certain things discussed here.
> So I'd pay 1000 dollars for a safe drug dispensing device rather than
> 100 dollars for a risky one, but I wouldn't pay 1000 dollars for a
> game that never crashed versus 100 for one that crashed every two
> months.
>
You'll not find a market for a 1000 dollar drug dispensing device if a
single manufacturer manages to produce one at the 100 price mark. The
reason being these products have to be certified, and being so both
would appear equally safe for the clientčle. It is the interest of the
manufacturer to use the technologies that minimize its cost to build,
test and certify the product.
Interestingly, from different markets, the search is for the same thing!
Cesar Rabak
> On Sat, 20 Jan 2007 14:44:26 -0200, in comp.lang.c , Cesar Rabak
> <csr...@yahoo.com.br> wrote:
>
>> In fact, I did not 'miss', but let's put in business context:
>
> Okay, lets.
>
>> if we
>> agree that for writing a certain piece of software in C it is required
>> more attention, care, <you name it> which ultimately equates to more
>> work, then we have an issue on the choice of the language (or more
>> exactly speaking its underlying technology and philosophy).
>
> And of programmers. Moral: Don't write mission critical programmes
> using fresh grads from law school who did Comp Sci in their spare
> time.
>
Mark McIntyre
<csr...@yahoo.com.br> wrote:
>You'll not find a market for a 1000 dollar drug dispensing device if a
>single manufacturer manages to produce one at the 100 price mark.
Sure you will - if your drug is safer, more effective or has fewer
side-effects. Why do you think they sell Humira when Voltarol exists?
The point was that the cost is linked to the amount of safety. Cheap
drugs are either proven safe by longevity of previous patients, or
untested.
Ian Collins
> Ian Collins <ian-...@hotmail.com> writes:
> [...]
>
>>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.
>
>
> Yes, C arrays are objects. See the definition of the word "object" in
> the C standard. <OT>The C++ standard's definition is similar.</OT>
>
Thanks for the correction, I'll choose my terms more carefully in future.
I still stand by the the last sentence - if you want a feature not in C,
choose a language that offers it.
--
Ian Collins.
Cesar Rabak
> On Sat, 20 Jan 2007 16:59:00 -0200, in comp.lang.c , Cesar Rabak
> <csr...@yahoo.com.br> wrote:
>
>> You'll not find a market for a 1000 dollar drug dispensing device if a
>> single manufacturer manages to produce one at the 100 price mark.
>
> Sure you will - if your drug is safer, more effective or has fewer
> side-effects. Why do you think they sell Humira when Voltarol exists?
>
> The point was that the cost is linked to the amount of safety. Cheap
> drugs are either proven safe by longevity of previous patients, or
> untested.
>
Non sequitur. We were discussing a drug *dispensing* device.
Keith Thompson
[...]
> Pure nonsense.
>
> No arguments. C is the best thing since sliced bread, and if the
> language has a bug it is not a bug, it is just that YOU are too
> stupid to use it.
>
> Heathfield, and others use the same "argument" over and over. The
> language is flawless, it is just the stupid programmers. To hear
> them, they never had a crash in their lives.
>
> Of course, saying that here is easy.
jacob, please consider giving up sarcasm. You don't do it well.
--
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.
Keith Thompson
[...]
> Secondly he noted that its false that _all_ memory overruns are fatal.
> This is completely true, your hyperbole and other nonsense
> notwithstanding. Consider a simple case - two adjacent arrays of 10
> chars each. Overwriting the 1st char of the 2nd array by mistake will
> be annoying maybe, confusing possibly. Fatal no.
It's entirely possible that overwriting the first element of a char
array could have fatal consequences. It's won't be *immediately*
fatal, but any data corruption has the potential of arbitrarily bad
consequences when the incorrect data is used.
Suppose the array in question is used as a printf format string, and
suppose its value is changed from "Hello, world\n" to "%ello, world\n".
This is likely to result in undefined behavior when the format string
is used.
Your basic point is correct, though: overwriting an array is not 100%
guaranteed fatal. The results of undefined behavior can *sometimes*
be innocuous.
jacob navia
> On Sat, 20 Jan 2007 18:25:21 +0100, in comp.lang.c , jacob navia
> <ja...@jacob.remcomp.fr> wrote:
>
>
>>Malcolm McLean a écrit :
>>
>>
>>>So I'd pay 1000 dollars for a safe drug dispensing device rather than 100
>>>dollars for a risky one, but I wouldn't pay 1000 dollars for a game that
>>>never crashed versus 100 for one that crashed every two months.
>>
>>I don't see your point. You mean C is just for writing games?
>
>
> Idiot.
BRAVO mcintyre!
What an argument!
As I told you before, you have never commanded anything different
than insults in this group.
Remember though, to be able to insult me I would have to give
*some* importance to what you say
:-)
Have nice evening
jacob navia
It is pointless, he doesn't seem to be able to read
Kenny McCormack
Keith Thompson <ks...@mib.org> wrote:
>jacob navia <ja...@jacob.remcomp.fr> writes:
>[...]
>> Pure nonsense.
>>
>> No arguments. C is the best thing since sliced bread, and if the
>> language has a bug it is not a bug, it is just that YOU are too
>> stupid to use it.
>>
>> Heathfield, and others use the same "argument" over and over. The
>> language is flawless, it is just the stupid programmers. To hear
>> them, they never had a crash in their lives.
>>
>> Of course, saying that here is easy.
>
>jacob, please consider giving up sarcasm. You don't do it well.
Keith, please consider giving up posting to this ng. You don't do it well.
(Not that this is likely to have any effect...)
Richard Heathfield
>
> "David T. Ashley" <d...@e3ft.com> wrote in message
>> 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).
>>
> No it isn't.
> An image is a two-dimensional object if anything is.
No it isn't. :-)
That is, an image is not *just* a two-dimensional object.
> However what good is an image algorithm that will only work on one size of
> image? In practise, you need to pass the dimensions in at run-time. Which
> means treating it as a 1d array and manually calculating the offset.
Here's how I do it:
struct clc_fbuf_
{
unsigned long **pixel;
int has_transparency;
unsigned long transparency_rgb;
unsigned long background;
size_t width;
size_t height;
int drawmode;
int restrict_to_selection;
};
pixel points to a bunch of row pointers, so pixel[r][c] identifies a given
pixel in the image.
> It would have been very easy to add some decent syntax to the language.
It's already got plenty of decent syntax.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.