181  4960 
jacob navia wrote:
>
.... 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>
Ian Collins <ia******@hotmail.comwrites:
[...]
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.
--
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.
CBFalconer wrote:
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
Ben Pfaff wrote:
jacob navia <ja***@jacob.remcomp.frwrites:
<snip>
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?
I appreciate the responses. Much food for thought!
Zach
"santosh" <sa*********@gmail.comwrites:
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_
"Ian Collins" <ia******@hotmail.comwrote
<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>
Or the vectors are too difficult to interface to other code that expects
arrays of integers.
Join my campaign for 64-bit ints. We need one representation of data in the
machine.
"Zach" <ne****@gmail.comwrote 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/Critici...mming_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.
Malcolm McLean wrote:
>
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
Ben Pfaff said:
"santosh" <sa*********@gmail.comwrites:
>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.
"Zach" <ne****@gmail.comwrote in message
Malcolm McLean wrote:
>>
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?
There is no particualer reason why a character, i.e. a human-readable glyph
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.
Malcolm McLean wrote:
"Zach" <ne****@gmail.comwrote 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/Critici...mming_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.
<snip>
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.
"kyle york" <ky***@cisco.comwrote 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.
Malcolm McLean a écrit :
"kyle york" <ky***@cisco.comwrote 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.
Besides, instead of just exit() you can have OTHER exit
strategies like lonjmp to a restart point, for instance
Malcolm McLean wrote:
"kyle york" <ky***@cisco.comwrote 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.
--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
"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
CBFalconer escreveu:
Malcolm McLean wrote:
>"kyle york" <ky***@cisco.comwrote 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.
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?
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).
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.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain, - www.
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'mon. You never make mistakes?
The language should do this checking automatically for you. That's all
we are proposing.
jacob
Richard Heathfield escreveu:
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 itwhich 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
jacob navia said:
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.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain, - www.
Cesar Rabak a écrit :
CBFalconer escreveu:
>Malcolm McLean wrote:
>>"kyle york" <ky***@cisco.comwrote 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.
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.
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
"Cesar Rabak" <cs*****@yahoo.com.brwrote 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.
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.
"santosh" <sa*********@gmail.comwrote 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.
Denis Ritchie, half of the C creator's team, was a great critic of const. I
think he was right - as an aid to documentation it is good, but as a
programming construct causes more problems than it solves.
Malcolm McLean a écrit :
"Cesar Rabak" <cs*****@yahoo.com.brwrote 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.
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?
jacob navia escreveu:
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'mon. You never make mistakes?
The language should do this checking automatically for you. That's
all we are proposing.
jacob, in this case I read Chuck's comment differently: for having the
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!
"David T. Ashley" <dt*@e3ft.comwrote 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.
"Malcolm McLean" <re*******@btinternet.comwrites:
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
On Sat, 20 Jan 2007 00:25:58 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>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
On Sat, 20 Jan 2007 00:30:29 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>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
"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
On Sat, 20 Jan 2007 01:05:55 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>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
"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
On Sat, 20 Jan 2007 00:57:55 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>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
"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
On Fri, 19 Jan 2007 22:04:20 -0200, in comp.lang.c , Cesar Rabak
<cs*****@yahoo.com.brwrote:
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
"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
On Sat, 20 Jan 2007 12:27:03 -0000, in comp.lang.c , "Malcolm McLean"
<re*******@btinternet.comwrote:
>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
"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
On Sat, 20 Jan 2007 14:44:26 -0200, in comp.lang.c , Cesar Rabak
<cs*****@yahoo.com.brwrote:
>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 itwhich 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
"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
On Sat, 20 Jan 2007 18:10:39 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>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
"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
On Sat, 20 Jan 2007 18:25:21 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>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.
--
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
Richard Heathfield escreveu:
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.
jacob navia escreveu:
Cesar Rabak a écrit :
>CBFalconer escreveu:
[snipped]
>>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.
Malcolm McLean wrote:
"santosh" <sa*********@gmail.comwrote 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.
Denis Ritchie, half of the C creator's team, was a great critic of const. I
think he was right - as an aid to documentation it is good, but as a
programming construct causes more problems than it solves.
Dennis was not half of a team. Dennis was the creator and Brian his
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 ---
Malcolm McLean escreveu:
"Cesar Rabak" <cs*****@yahoo.com.brwrote 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.
I might seem so, but as the Sweeny Report shows http://www.st.cs.uni-sb.de/edu/semin...ocs/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!
Mark McIntyre escreveu:
On Sat, 20 Jan 2007 14:44:26 -0200, in comp.lang.c , Cesar Rabak
<cs*****@yahoo.com.brwrote:
>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 itwhich 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.
Yup, for the C language more so...
On Sat, 20 Jan 2007 16:59:00 -0200, in comp.lang.c , Cesar Rabak
<cs*****@yahoo.com.brwrote:
>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.
--
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
Keith Thompson wrote:
Ian Collins <ia******@hotmail.comwrites:
[...]
>>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.
Mark McIntyre escreveu:
On Sat, 20 Jan 2007 16:59:00 -0200, in comp.lang.c , Cesar Rabak
<cs*****@yahoo.com.brwrote:
>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.
jacob navia <ja***@jacob.remcomp.frwrites:
[...]
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.
Mark McIntyre <ma**********@spamcop.netwrites:
[...]
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.
--
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.
Mark McIntyre a écrit :
On Sat, 20 Jan 2007 18:25:21 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>>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
Cesar Rabak a écrit :
Mark McIntyre escreveu:
>On Sat, 20 Jan 2007 16:59:00 -0200, in comp.lang.c , Cesar Rabak
<cs*****@yahoo.com.brwrote:
>>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.
It is pointless, he doesn't seem to be able to read
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
>jacob navia <ja***@jacob.remcomp.frwrites:
[...]
>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...)
Malcolm McLean said:
>
"David T. Ashley" <dt*@e3ft.comwrote 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. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Andrew Chalk |
last post by:
A few year's ago someone (eminent in the C++ community) criticicized the use
of exceptions on the grounds that they introduced "a whole shadow type
system"). Can anyone recall the article and...
|
by: Matt Kruse |
last post by:
I've looked at some of the popular javascript libraries for use by
developers on upcoming projects:
jQuery, Moo Tools, YUI, Prototype (+Dojo), Fork
Of these most popular libraries, jQuery seems...
|
by: lorlarz |
last post by:
Although I believe your criticisms of jQuery are without merit, I have
tried to see the fuss in a positive light. I, thusly, have decided
that perhaps there is a need for YET further transparency...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
| |
