An Authors View on C

[Fao, Sean]

A guy at http://www.embedded.com gave his opinion on the C language and I
was shocked to see the number of supporters for the author.**I*also*find*it
hard to believe that 99% of all code has memory leaks; but, I suppose I
could be wrong.

See what you think:

http://www.embedded.com
showArticle.jhtml;jsessionid=4DOBHEJ2YZUKUQSNDBCSK HQ?articleID=15306089

Sean
--
Remove I-WANT-NO-SPAM to reply in email.

[Richard Heathfield]

Fao, Sean wrote:

A guy at http://www.embedded.com gave his opinion on the C language and I
was shocked to see the number of supporters for the author. I also find
it hard to believe that 99% of all code has memory leaks; but, I suppose I
could be wrong.

See what you think:

http://www.embedded.com
showArticle.jhtml;jsessionid=4DOBHEJ2YZUKUQSNDBCSK HQ?articleID=15306089

It is true that C allows you to do stupid things. It is also true that C
allows you to do clever things. C doesn't get in your way. It's up to you.
If you'd rather it were up to the language to protect you from yourself,
you're using the wrong language. C is powerful, like a chainsaw. And just
like a chainsaw, it can do a lot of damage in the wrong hands. That doesn't
mean that C is a bad language, any more than chainsaws are bad tools.

The 99% figure is wrong. Only 90% of PC programs have memory leaks. (So
prove me wrong.) Cf Sturgeon's Law.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[jacob navia]

"Fao, Sean" <en**********@yahoo.comI-WANT-NO-SPAM> wrote in message
news:9v**********************@news1.news.adelphia. net...

A guy at http://www.embedded.com gave his opinion on the C language and I
was shocked to see the number of supporters for the author. I also find it
hard to believe that 99% of all code has memory leaks; but, I suppose I
could be wrong.

See what you think:

http://www.embedded.com
showArticle.jhtml;jsessionid=4DOBHEJ2YZUKUQSNDBCSK HQ?articleID=15306089

That article has many points. The basic principle is stated at the start:

C, the most popular of all embedded languages, is an utter disaster, a bizarre hodgepodge meant to
give the programmer far too much control over the computer. C++ isn't much better. The languages are
designed to provide infinite flexibility, to let the developer do anything that can be done on the
computer.

<<
You have to limit what the programmer can do to avoid mistakes. This is a bad conclusion from real
facts like the difficulty of using correctly malloc and free.

I proposed garbage collection as the means of solving this. GC allows you to avoid
malloc and free. See http://www.cs.virginia.edu/~lcc-win32.

Another real fact is the primitive string type in C and the absence of bounds
checking of arrays, specially strings. The use of a bounded array type is long
overdue and C will continue to have critics that will point out this defficiency in the
language as long as no solution is proposed by the standard.

It is a pity that we go on with a badly conceived data type. Bounded strings would
be really a bonus for the language. We are in the final phase of releasing a string
package for the above implementation.

Bounded strings are much faster than traditional strings. The strlen() function
is just a memory read: you just access the "size" field.

Other functions like strcat and others can be implemented *much* faster and
without any buffer overflows.

The whole package is easier to do with the garbage collector.

The other points in the article are ridiculous. He says, for instance

C has no formatting rules. It's easy and usual to write source in astonishingly cryptic ways. Any
language that allows utterly random use of the ENTER key (it's perfectly legit to hit ENTER after
almost every character in C) is more an encryption tool than an aid to creating reliable and
maintainable code.

<<

Now, if you can't even format your own program as you seem fit...

jacob

[Joe Wright]

Richard Heathfield wrote:

Fao, Sean wrote:

A guy at http://www.embedded.com gave his opinion on the C language and I
was shocked to see the number of supporters for the author. I also find
it hard to believe that 99% of all code has memory leaks; but, I suppose I
could be wrong.

See what you think:

http://www.embedded.com
showArticle.jhtml;jsessionid=4DOBHEJ2YZUKUQSNDBCSK HQ?articleID=15306089

It is true that C allows you to do stupid things. It is also true that C
allows you to do clever things. C doesn't get in your way. It's up to you.
If you'd rather it were up to the language to protect you from yourself,
you're using the wrong language. C is powerful, like a chainsaw. And just
like a chainsaw, it can do a lot of damage in the wrong hands. That doesn't
mean that C is a bad language, any more than chainsaws are bad tools.

The 99% figure is wrong. Only 90% of PC programs have memory leaks. (So
prove me wrong.) Cf Sturgeon's Law.

The chainsaw analogy notwithstanding, C allows me to "scrape paint" all
the way down to "bare metal". It is precise as a fine surgeon's scalpel.
Memory leaks, whatever they are, have nothing to do with C. Statistics
show that 98.7 percent of all statistics are made up. I don't know what
caviar has to do with this. Dammit, where's my drink?
--
Joe Wright http://www.jw-wright.com
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Ricardo Gibert]

C is fine language for good programmers. It's a bad language for bad programmers.

IMO the language should have never become popular, since most programmers are not good enough for the language. However, human
nature being what it is, most programmers do not see themselves as being the bad programmers that they are.
"Fao, Sean" <en**********@yahoo.comI-WANT-NO-SPAM> wrote in message news:9v**********************@news1.news.adelphia. net...

A guy at http://www.embedded.com gave his opinion on the C language and I
was shocked to see the number of supporters for the author. I also find it
hard to believe that 99% of all code has memory leaks; but, I suppose I
could be wrong.

See what you think:

http://www.embedded.com
showArticle.jhtml;jsessionid=4DOBHEJ2YZUKUQSNDBCSK HQ?articleID=15306089

Sean
--
Remove I-WANT-NO-SPAM to reply in email.

[Malcolm]

"jacob navia" <ja*********@jacob.remcomp.fr> wrote in message

You have to limit what the programmer can do to avoid mistakes. This > is a bad conclusion from real facts like the difficulty of using correctly malloc and free.
The malloc free problem is the consequence of paring the language down so
that these are just ordinary functions.
I proposed garbage collection as the means of solving this. GC allows > you to avoid malloc and free. See http://www.cs.virginia.edu/~lccwin32.
There's a case for garbage collection, but why not just use C++ and the
standard template library if you want a higher-level langauge?
Another real fact is the primitive string type in C and the absence of
bounds checking of arrays, specially strings. The use of a bounded
array type is long overdue and C will continue to have critics that will
point out this defficiency in the language as long as no solution is
proposed by the standard.
Just about everyone has a go at a better string library for C. Asciiz
strings are easy to implement and work with, and in most programs string
handling isn't a bottleneck. Again, why not go for C++ if you want a
built-in string class?
Bounded strings are much faster than traditional strings. The strlen()
function is just a memory read: you just access the "size" field.
Sure. But you're changing the spirit of the langauge by putting in support
for them eg

string foo = "FRED"; actually fills a structure with information about the
string literal.
Other functions like strcat and others can be implemented *much*
faster and without any buffer overflows.
Though implementation time includes programmer time as well as CPU time, and
for many applications is much more important.
The whole package is easier to do with the garbage collector.

Exactly. Once you start messing about with structures and dynamically memory
for strings you have to free them, adding complexity to your program, or you
have to have some automatic garbage scheme, adding complexity to the
compiler.

[j]

"Fao, Sean" <en**********@yahoo.comI-WANT-NO-SPAM> wrote in message
news:9v**********************@news1.news.adelphia. net...

A guy at http://www.embedded.com gave his opinion on the C language and I
was shocked to see the number of supporters for the author. I also find it
hard to believe that 99% of all code has memory leaks; but, I suppose I
could be wrong.

See what you think:

http://www.embedded.com
showArticle.jhtml;jsessionid=4DOBHEJ2YZUKUQSNDBCSK HQ?articleID=15306089

Sean
--
Remove I-WANT-NO-SPAM to reply in email.

``C, the most popular of all embedded languages, is an utter disaster, a
bizarre hodgepodge meant to give the programmer far too much control over
the computer.''

Too much of what he says is aimed around miniscule problems that clueless C
programmers can fall into.
Oh, I can dereference a null pointer, I don't have to get a diagnostic for
doing so, that is right. But only a beginner would so. And as such, such a
novice shouldn't be using the language for _any_ serious development until
they have actually understood the language. I really don't see the logic.
(Using a chainsaw as an example after reading Richard Heathfield's post) I
can walk around with a chainsaw and cut people up with it, but does this
mean that I should? And because I can do this, does it make a chainsaw a
crappy tool?

Understanding the semantics of C is not something that will be achieved in
21 days, 24 hours, or what have you. What does this guy want? Does he
actually want to learn the pitfalls of C so he knows what to avoid and to
better himself as a programmer in C or does he want to be able to use a
language which is completely faultless? Oh, perhaps he would like to design
such a language that is entirely faultless. I think his criticisms are
extremely poor and could be concluded by anyone that say, finished reading
``Teach Yourself C In 21 Days".
``But no language should allow stupid mistakes like buffer overruns or
undetected array overflows. ''

They are only mistakes when the careless C programmer is using them in
incorrect situations.
I myself, have never had a problem with buffer overflows. You might find
yourself fall afoul to this issue if you haven't given the algorithm for
solving a problem, some actual thought.

buffer overflows, heap overflows, double frees', one byte overflows/frame
pointer overwrite, integer overflows; If you fall afoul to any of these,
that is the problem of the bloody careless programmer, not the language.

``Geodesic claims 99% of all PC programs (most written in C and C++ of
course) have memory leaks, all caused by poor use of malloc() and free().''

And of what percentage is this done by the careless programmer? I wouldn't
be surprised if careless programmers counted for the majority. But he just
fails to hint at that because it wouldn't make his poor point.

``Here's a C hint that will improve your job security: embrace double
indirection. Even better, try triple. Real programmers use quadruple. The
only limit to the number of asterisks placed in front of a pointer is the
size of one's cojones or how adventurous you feel. ''

Another poor criticism. Again, who would use excessive indirection
constantly? If not for an ioccc entry then I would say a beginner. But then,
the only people fooled by this article would be beginners of C.

``Even something as simple as integer math produces unexpected results:
20,000 + 20,000 is (ta-da) a negative number. Is this cool or what! ''

He could achieve proper results with the 'U' suffix to denote an integer
constant of unsigned int, is that cool or what! But whose fault is that?
Certainly not the language's.

``C has no formatting rules. It's easy and usual to write source in
astonishingly cryptic ways. Any language that allows utterly random use of
the ENTER key (it's perfectly legit to hit ENTER after almost every
character in C) is more an encryption tool than an aid to creating reliable
and maintainable code. ''

You would have to be a complete retard to not be able to format your code
correctly. This is _another_ poor criticism.

``No other language has an obfuscated code contest. Win by writing code that
works but that's so convoluted no C expert can understand why. Most of the
entries look like a two year old hit a few thousand random keys. And no, I'm
not putting the URL of the contest here; these people are code terrorists
who should be hunted down and shot. ''

Complete drivel. These contests are done only for fun. No serious
applications are being developed.

``A great programming language should encourage users to create perfect
code.''

He should define ``perfect''. This of course is something based on ones
ideological reasoning.
I personally think one can achieve ``perfect''(robust, flawless) code in C
by undertsanding its pitfalls.

[Fao, Sean]

Joe Wright wrote:

Statistics show that 98.7 percent of all statistics
are made up.

Is this one of them? ;-)

--
Remove I-WANT-NO-SPAM to reply in email.

[Eddahbi Karim]

On Sun, 19 Oct 2003 20:06:29 -0700
"j" <ja**********@bellsouth.net> wrote:

He should define ``perfect''. This of course is something based on
ones ideological reasoning.
I personally think one can achieve ``perfect''(robust, flawless) code
in C by undertsanding its pitfalls.

I don't know how he can say "perfect" a code.
Most of the problems he says was about careless programmers.

A careless programmer doesn't perfect his code... because he doesn't
care about.

--
--
ThE_TemPLaR

[brendon]

On Sun, 19 Oct 2003 20:06:29 +0000, j wrote:

But only a beginner would so. And as such, such a novice shouldn't be using the language for _any_ serious development until
they have actually understood the language. I really don't see the
logic.
myself being a beginner in c i have a bit of understanding of
pascal/delphi. I agree with you on that statement. it doesn't matter
what language you use, you shouldn't be doing any serious stuff until you
know excatly what you are doing, and not be afraid to ask for help if you
suspect a problem, experienced people are only to willing to help as i
have found out in the past.
(Using a chainsaw as an example after reading Richard Heathfield's post) I
can walk around with a chainsaw and cut people up with it, but does this
mean that I should? And because I can do this, does it make a chainsaw a
crappy tool?
execatly

Understanding the semantics of C is not something that will be achieved in
21 days, 24 hours, or what have you.
he might have read those books but you have to experiment with the
language and not be afraid to ask. not doing that sort of thing the
person concerned ain't going to get very far. reading the books are fine
but it is going beyond what is written is the idea.

``But no language should allow stupid mistakes like buffer overruns or
undetected array overflows. ''

debugging, and using testing.
They are only mistakes when the careless C programmer is using them in
incorrect situations.
I myself, have never had a problem with buffer overflows. You might find
yourself fall afoul to this issue if you haven't given the algorithm for
solving a problem, some actual thought.
so true
``Geodesic claims 99% of all PC programs (most written in C and C++ of
course) have memory leaks, all caused by poor use of malloc() and free().''
And of what percentage is this done by the careless programmer? I wouldn't
be surprised if careless programmers counted for the majority. But he just
fails to hint at that because it wouldn't make his poor point.

if a delphi news group, i had seen a similar type of critisism<spelling>
and like you say it was the programmer fault, his code was shotty, and
hard to follow, and this particular person had mem leaks, and process
leaks(cpu maxing out).

[jacob navia]

"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote in message
news:bm**********@newsg3.svr.pol.co.uk...

There's a case for garbage collection, but why not just use C++ and the
standard template library if you want a higher-level langauge?

Because C++ suffers from obesity. Too complex for a human mind.
There is no 100% compliant compiler for C++ besides Comeau C++ and the
EDG front end.

[James Antill]

On Sun, 19 Oct 2003 23:51:35 +0200, jacob navia wrote:

You have to limit what the programmer can do to avoid mistakes. This is a bad conclusion from real
facts like the difficulty of using correctly malloc and free.

I proposed garbage collection as the means of solving this. GC allows you to avoid
malloc and free. See http://www.cs.virginia.edu/~lcc-win32.
Boehm GC has been around a _long_ time for C programs that want it.
Another real fact is the primitive string type in C and the absence of bounds
checking of arrays, specially strings. The use of a bounded array type is long
overdue and C will continue to have critics that will point out this defficiency in the
language as long as no solution is proposed by the standard.

It is a pity that we go on with a badly conceived data type. Bounded strings would
be really a bonus for the language. We are in the final phase of releasing a string
package for the above implementation.
Oh, another one. See http://www.and.org/vstr/comparison.html ... I'm
pretty sure your implementation has been tried and tested before.
Bounded strings are much faster than traditional strings. The strlen() function
is just a memory read: you just access the "size" field.

Other functions like strcat and others can be implemented *much* faster and
without any buffer overflows.

The whole package is easier to do with the garbage collector.

I doubt that, I have implemented (and many others have too) a nice string
API without having to resort to not implement resource deallocation.

--
James Antill -- ja***@and.org
Need an efficient and powerful string library for C?
http://www.and.org/vstr/

[Jarno A Wuolijoki]

On Mon, 20 Oct 2003, Fao, Sean wrote:

Statistics show that 98.7 percent of all statistics
are made up.

Is this one of them? ;-)

Sounds quite credible to me. Besides, a quick googling shows that
the survey has even been performed several times:

"42.7 percent of all statistics are made up on the spot"
"78 percent of all statistics are made up on the spot"
"73 percent of all statistics are made up."
"78.6 percent of all statistics are made up on the spot."
"83 percent of all statistics are made up on the spot."
"47.62 percent of all statistics are made up on the spot?"
"88.2% of statistics are made up on the spot"
"33% of statistics are made up"

[Morris Dovey]

Fao, Sean wrote:

A guy at http://www.embedded.com gave his opinion on the C
language and I was shocked to see the number of supporters for
the author. I also find it hard to believe that 99% of all
code has memory leaks; but, I suppose I could be wrong.

Jack Ganssle wrote:

"A great programming language should encourage users to create
perfect code. It must bound our options, limit our freedom,
remove the degrees of freedom that lead to stupid bugs."

Mr Ganssle presents an interesting viewpoint. I was attracted to
C precisely because I saw the language as a tool that would
expand my options and set me free to explore new solution
methodologies /without/ having to spend 90% of my time and effort
defeating the 'safeguards' that prevented getting the job done.
I've continued using the language because it has been the best
(for project- and task-specific definitions of /best/) for nearly
all of my projects for more than twenty years.

If Mr. Ganssle has a need for a language with Ada-like
characteristics, then he should probably /use/ Ada to satisfy his
needs. To me his complaints are comparable to a whining about how
his cat doesn't bark when there's a stranger at the door.

[Sorry, Jack - stupidity hath no remedy.]
--
Morris Dovey
West Des Moines, Iowa USA
C links at http://www.iedu.com/c

[Irrwahn Grausewitz]

"Fao, Sean" <en**********@yahoo.comI-WANT-NO-SPAM> wrote:

Joe Wright wrote:

Statistics show that 98.7 percent of all statistics
are made up.

Is this one of them? ;-)

Nope, it's one of the other 21.3 percent that are just wrong. ;-)

--
Irrwahn
(ir*******@freenet.de)

[pete]

j wrote:

"Fao, Sean" <en**********@yahoo.comI-WANT-NO-SPAM> wrote in message
news:9v**********************@news1.news.adelphia. net...

A guy at http://www.embedded.com gave his opinion on the C language

``Even something as simple as integer math produces unexpected
results: 20,000 + 20,000 is (ta-da) a negative number.
Is this cool or what! ''
(20000 + 20000) is not a portable expression.
If it looks negative, then it's undefined.
He could achieve proper results with the 'U' suffix to
denote an integer constant of unsigned int, is that cool or what!

.... or even the 'L' suffix, if he wants a signed type.

Choosing types with enough precission
to hold the results of operations,
is not an advanced topic in C.

--
pete

[Sam Hobbs]

On Sun, 19 Oct 2003 19:21:41 GMT, "Fao, Sean"
<en**********@yahoo.comI-WANT-NO-SPAM> wrote:

A guy at http://www.embedded.com gave his opinion on the C language and I
was shocked to see the number of supporters for the author.**I*also*find*it
hard to believe that 99% of all code has memory leaks; but, I suppose I
could be wrong.

The guy is Jack Ganssle. Pretty well respected in the area of embedded
programming.

Interesting to note that he says among other things:
". . . I do like programming in C."
and does not mean it facetiously.

Even the article title: "My Love-Hate Relationship with C" indicates
that he is not opposed to the language.

Also interesting to note that it is not Jack who claims that 99% of
programs have memory leaks, but a company which sells software to help
with such things as memory leaks.

As for the number of people who "agreed" with him, SO WHAT. Surely we
all know that there are lots of people out there who don't like the
features of C -- some of them even offered their own ideas in this
thread.

Sam

[Dan Pop]

In <9v**********************@news1.news.adelphia.ne t> "Fao, Sean" <en**********@yahoo.comI-WANT-NO-SPAM> writes:

A guy at http://www.embedded.com gave his opinion on the C language and I
was shocked to see the number of supporters for the author.**I*also*find*it
hard to believe that 99% of all code has memory leaks; but, I suppose I
could be wrong.

See what you think:

http://www.embedded.com
showArticle.jhtml;jsessionid=4DOBHEJ2YZUKUQSNDBCS KHQ?articleID=15306089

The guy didn't understand a very simple thing: both the strength and the
weakness of the language come from the fact that it was designed to
provide a *thin* abstraction layer over the bare metal. If you want/need
a thicker layer, choosing C is a mistake. That's why nobody's going to
change the fundamental design of C. If you need Ada, use Ada.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Arthur J. O'Dwyer]

On Mon, 20 Oct 2003, pete wrote:

j wrote:

Sean Fao wrote...

A guy at http://www.embedded.com gave his opinion on the C language

``Even something as simple as integer math produces unexpected
results: 20,000 + 20,000 is (ta-da) a negative number.
Is this cool or what! ''

(20000 + 20000) is not a portable expression.
If it looks negative, then it's undefined.

Not at all.

if( (20,000 + 20,000) == (-7,000) )
puts("C sucks!");

;-)

-Arthur

[Joe Wright]

Arthur J. O'Dwyer wrote:

On Mon, 20 Oct 2003, pete wrote:

j wrote:

Sean Fao wrote...
> A guy at http://www.embedded.com gave his opinion on the C language

``Even something as simple as integer math produces unexpected
results: 20,000 + 20,000 is (ta-da) a negative number.
Is this cool or what! ''

(20000 + 20000) is not a portable expression.
If it looks negative, then it's undefined.

Not at all.

if( (20,000 + 20,000) == (-7,000) )
puts("C sucks!");

;-)

What do you suppose those commas will do? Did you know that ajo is
Spanish for garlic?

--
Joe Wright http://www.jw-wright.com
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Kevin D. Quitt]

On Sun, 19 Oct 2003 21:57:19 GMT, Joe Wright <jo********@earthlink.net>
wrote:

Statistics
show that 98.7 percent of all statistics are made up.

My .sig for over 20 years:
--
#include <standard.disclaimer>
_
Kevin D Quitt USA 91387-4454 96.37% of all statistics are made up
Per the FCA, this address may not be added to any commercial mail list

[Jirka Klaue]

Joe Wright wrote:

Arthur J. O'Dwyer wrote:

if( (20,000 + 20,000) == (-7,000) )
puts("C sucks!");

What do you suppose those commas will do?

Why did he include all these ()? What do *you* think?

Jirka

[Joe Wright]

Kevin D. Quitt wrote:

On Sun, 19 Oct 2003 21:57:19 GMT, Joe Wright <jo********@earthlink.net>
wrote:

Statistics
show that 98.7 percent of all statistics are made up.

My .sig for over 20 years:

--
#include <standard.disclaimer>
_
Kevin D Quitt USA 91387-4454 96.37% of all statistics are made up
Per the FCA, this address may not be added to any commercial mail list

So I'm off by 2.33 percent. I made it up too. So sue me. :-)
--
Joe Wright http://www.jw-wright.com
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Gordon Burditt]

>A guy at http://www.embedded.com gave his opinion on the C language and I

was shocked to see the number of supporters for the author.**I*also*find*it
hard to believe that 99% of all code has memory leaks; but, I suppose I
could be wrong.

I find it hard to believe that even 90% of all C code even uses
dynamic memory allocation. I'll even let you count use of fopen()
as a memory leak if you fail to fclose() the file (since that's a
file leak and probably a memory leak since buffers are likely
allocated dynamically by the implementation). I still don't think
90% of all programs use either dynamic memory allocation OR open
files (other than the pre-opened stdin, stdout, and stderr).

Show me a way to create a memory leak in standard C without using
malloc, free, calloc, realloc, fopen, or freopen. (Leaks internal
to the standard library implementation don't count: that's the
implementation's problem.)

Gordon L. Burditt

[Ed Morton]

On 10/20/2003 11:24 AM, Gordon Burditt wrote:

A guy at http://www.embedded.com gave his opinion on the C language and I
was shocked to see the number of supporters for the author. I also find it
hard to believe that 99% of all code has memory leaks; but, I suppose I
could be wrong.

I find it hard to believe that even 90% of all C code even uses
dynamic memory allocation. I'll even let you count use of fopen()
as a memory leak if you fail to fclose() the file (since that's a
file leak and probably a memory leak since buffers are likely
allocated dynamically by the implementation). I still don't think
90% of all programs use either dynamic memory allocation OR open
files (other than the pre-opened stdin, stdout, and stderr).

Show me a way to create a memory leak in standard C without using
malloc, free, calloc, realloc, fopen, or freopen. (Leaks internal
to the standard library implementation don't count: that's the
implementation's problem.)

Gordon L. Burditt

Would this count as a memory leak:

void doStuff() {
char buf[10];
doStuff();
}

i.e. in general a buggy recursive-descent program that grabs some stack on each
invocation but fails to return every time it should.

Regards,

Ed.

[Joe Wright]

Jirka Klaue wrote:

Joe Wright wrote:

Arthur J. O'Dwyer wrote:

if( (20,000 + 20,000) == (-7,000) )
puts("C sucks!");

What do you suppose those commas will do?

Why did he include all these ()? What do *you* think?

Jirka, I don't know why. The parens have no effect. The comma in an
expression separates its left and right parts, the right part surviving.
Thus 20,000 == 0 and -7,000 == 0 and the if () above is true.
Why do *you* think he included the parens?
--
Joe Wright http://www.jw-wright.com
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Dan Pop]

In <bn********@library2.airnews.net> go***********@sneaky.lerctr.org (Gordon Burditt) writes:

Show me a way to create a memory leak in standard C without using
malloc, free, calloc, realloc, fopen, or freopen.

Show me a way to create a memory leak in standard C *by* using free ;-)

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Christopher Benson-Manica]

Dan Pop <Da*****@cern.ch> spoke thus:

Show me a way to create a memory leak in standard C *by* using free ;-)

Does undefined behavior count?

free( 666 );
free( (void *)42 );
free( "Pretend free() works like printf() and see what happens!\n" );

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[Mike Wahler]

"Ed Morton" <mo****************@Lucent.com> wrote in message
news:3F**************@Lucent.com...

Would this count as a memory leak:

void doStuff() {
char buf[10];
doStuff();
}

I'd call that terminal constipation.

Much more likely to result in an explosion than a 'leak'.

:-)
-Mike

[Dan Pop]

In <3F**************@Lucent.com> Ed Morton <mo****************@Lucent.com> writes:

Would this count as a memory leak:

void doStuff() {
char buf[10];
doStuff();
}

i.e. in general a buggy recursive-descent program that grabs some stack on each
invocation but fails to return every time it should.

This either crashes the program by running out of memory or eventually
returns to the original caller, and all the allocated memory is reclaimed.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[E. Robert Tisdale]

Fao, Sean wrote:

A guy at http://www.embedded.com gave his opinion on the C language
and I was shocked to see the number of supporters for the author.
I also find it hard to believe that 99% of all code has memory leaks;
but, I suppose I could be wrong.

See what you think:

http://www.embedded.com

Take a look at

http://www.ganssle.com/bio.htm

Evidently, Jack Ganssle makes his living by lecturing and writing
articles and books on embedded computing.
He doesn't appear to have any other credentials
in embedded computing or in C programming.

[Alan Balmer]

On Mon, 20 Oct 2003 11:15:15 -0700, "E. Robert Tisdale"
<E.**************@jpl.nasa.gov> wrote:

Fao, Sean wrote:

A guy at http://www.embedded.com gave his opinion on the C language
and I was shocked to see the number of supporters for the author.
I also find it hard to believe that 99% of all code has memory leaks;
but, I suppose I could be wrong.

See what you think:

http://www.embedded.com

Take a look at

http://www.ganssle.com/bio.htm

Evidently, Jack Ganssle makes his living by lecturing and writing
articles and books on embedded computing.
He doesn't appear to have any other credentials
in embedded computing or in C programming.

Wrong.

Ganssle has been in the embedded systems business as developer,
entrepreneur, educator, author, etc. since around 1970, give or take a
couple of years. He's well respected in the field, and was writing
8008 assembler before he wrote C.

--
Al Balmer
Balmer Consulting
re************************@att.net

[Arthur J. O'Dwyer]

On Mon, 20 Oct 2003, Gordon Burditt wrote:

Show me a way to create a memory leak in standard C without using
malloc, free, calloc, realloc, fopen, or freopen. (Leaks internal
to the standard library implementation don't count: that's the
implementation's problem.)

From N869:

#include <setjmp.h>
jmp_buf buf;
void g(int n);
void h(int n);
int n = 6;

void f(void)
{
int x[n]; // OK, f is not terminated.
setjmp(buf);
g(n);
}

void g(int n)
{
int a[n]; // a may remain allocated.
h(n);
}

void h(int n)
{
int b[n]; // b may remain allocated.
longjmp(buf,2); // might cause memory loss.
}
;-)
-Arthur

[Arthur J. O'Dwyer]

On Mon, 20 Oct 2003, Joe Wright wrote:

Jirka Klaue wrote:

Joe Wright wrote:

Arthur J. O'Dwyer wrote:
>
> if( (20,000 + 20,000) == (-7,000) )
> puts("C sucks!");

What do you suppose those commas will do?

Why did he include all these ()? What do *you* think?

Jirka, I don't know why. The parens have no effect. The comma in an
expression separates its left and right parts, the right part surviving.
Thus 20,000 == 0 and -7,000 == 0 and the if () above is true.
Why do *you* think he included the parens?

Try it without the parentheses, and see whether C still sucks.
Then put them back, and consult your handy precedence table.
:-)

-Arthur

[Dave Vandervies]

In article <bm*********@hercules.btinternet.com>,
Richard Heathfield <bi****@eton.powernet.co.uk> wrote:

Fao, Sean wrote:

A guy at http://www.embedded.com gave his opinion on the C language and I
was shocked to see the number of supporters for the author. I also find
it hard to believe that 99% of all code has memory leaks; but, I suppose I
could be wrong.

See what you think:

http://www.embedded.com
showArticle.jhtml;jsessionid=4DOBHEJ2YZUKUQSNDBCSK HQ?articleID=15306089
It is true that C allows you to do stupid things. It is also true that C
allows you to do clever things. C doesn't get in your way. It's up to you.
If you'd rather it were up to the language to protect you from yourself,
you're using the wrong language. C is powerful, like a chainsaw. And just
like a chainsaw, it can do a lot of damage in the wrong hands. That doesn't
mean that C is a bad language, any more than chainsaws are bad tools.

Unlike a chainsaw, C is often used with most of the safety features
removed, disabled, or ignored.
This is more of a problem with C programmers than a problem with C,
but that doesn't stop it from being a valid problem.

This looks like as good an excuse as any to post this (seen in a thread
crossposted between a few other language newsgroups) here:
(ObTopic: It actually makes a valid point about C.)
--------
This seems like a good juncture to post my list of common myths and
misconceptions about popular programming languages. Contributions are
welcome; flames only if they're funny. Anyone who needs to see :) on
things to know they're meant in jest should stop reading now.
== Programming Language Myths ==

BASIC Myth: People who learn BASIC go on to learn other languages.
Reality: Most people who learn BASIC go on to find less nerdy ways of
writing "Mr. Gzabowski is a lame teacher" over and over again.

C Myth: C programs are insecure, full of buffer overflows and such.
Reality: C programs are only insecure if written by imperfect programmers.
Since all C programmers know that they are perfect, there's no
problem.

COBOL Myth: COBOL is dead.
Reality: It stalks from out the ancient vaults of death, its putrid mind
drawn to the blood of the living.

Forth Myth: Forth makes no sense.
Reality: backwards. think to have just you sense, perfect makes Forth

Java Myth: You need Java to do business applications.
Reality: You need Java to get a job.

Lisp Myth: Lisp is an interpreted language.
Reality: Lisp is COMPILED DAMMIT COMPILED! IT'S IN THE FUCKING STANDARD!!!

Pascal Myth: Pascal is a toy.
Reality: Oh, wait, that is not a myth, it is true ...

Perl Myth: Perl is impossible to read.
Reality: You are not taking enough psychedelics.

Python Myth: Python's only problem is the whitespace thing.
Reality: Python's only problem is that it is fucking slow.
--------

The 99% figure is wrong. Only 90% of PC programs have memory leaks. (So
prove me wrong.) Cf Sturgeon's Law.

Isn't there a corollary that states that Sturgeon's Law also applies
recursively to the remaining 10%?
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca
Have some pride, you're a physics major! You know deep in your heart
you're better than the rest of the slobs there, you should be able to
knock this course off easily. --Brian B. Rodenborn in comp.lang.c

[Dan Pop]

In <bn**********@chessie.cirr.com> Christopher Benson-Manica <at***@nospam.cyberspace.org> writes:

Dan Pop <Da*****@cern.ch> spoke thus:

Show me a way to create a memory leak in standard C *by* using free ;-)

Does undefined behavior count?

Where does the standard say that undefined behaviour results in memory
leaks?

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Christopher Benson-Manica]

Dan Pop <Da*****@cern.ch> spoke thus:

Where does the standard say that undefined behaviour results in memory
leaks?

It doesn't (I presume...), I was just being facetious. My mistake for
omitting the Standard-mandated winky-face. ;)

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[Joona I Palaste]

Dan Pop <Da*****@cern.ch> scribbled the following:

In <bn**********@chessie.cirr.com> Christopher Benson-Manica <at***@nospam.cyberspace.org> writes:

Dan Pop <Da*****@cern.ch> spoke thus:

Show me a way to create a memory leak in standard C *by* using free ;-)
Does undefined behavior count?

Where does the standard say that undefined behaviour results in memory
leaks?

Where does it say it doesn't?
(I had a similar discussion with Dan Pop once. I don't think I won that
argument. I'm not going to try to win this one. Just pointing this out.)

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Immanuel Kant but Genghis Khan."
- The Official Graffitist's Handbook

[Dan Pop]

In <bn**********@oravannahka.helsinki.fi> Joona I Palaste <pa*****@cc.helsinki.fi> writes:

Dan Pop <Da*****@cern.ch> scribbled the following:

In <bn**********@chessie.cirr.com> Christopher Benson-Manica <at***@nospam.cyberspace.org> writes:

Dan Pop <Da*****@cern.ch> spoke thus:

Show me a way to create a memory leak in standard C *by* using free ;-)

Does undefined behavior count?

Where does the standard say that undefined behaviour results in memory
leaks?

Where does it say it doesn't?

If it doesn't *guarantee* a memory leak, how can you prove that the code
in question generates one?

Are you unable to tell the difference between mandated behaviour and
allowed behaviour?

BTW, any language lawyer could trivially point out that even matching
any malloc call by a corresponding free call doesn't guarantee that
no memory leaks occur. The standard simply does not address the issue in
an unequivocal manner.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Joona I Palaste]

Dan Pop <Da*****@cern.ch> scribbled the following:

In <bn**********@oravannahka.helsinki.fi> Joona I Palaste <pa*****@cc.helsinki.fi> writes:

Dan Pop <Da*****@cern.ch> scribbled the following:

Where does the standard say that undefined behaviour results in memory
leaks?
Where does it say it doesn't?

If it doesn't *guarantee* a memory leak, how can you prove that the code
in question generates one? Are you unable to tell the difference between mandated behaviour and
allowed behaviour? BTW, any language lawyer could trivially point out that even matching
any malloc call by a corresponding free call doesn't guarantee that
no memory leaks occur. The standard simply does not address the issue in
an unequivocal manner.

Here is the part in my post that you snipped:
"(I had a similar discussion with Dan Pop once. I don't think I won that
argument. I'm not going to try to win this one. Just pointing this out.)"

Keeping that in mind, I won't argue further. Those interested in the
arguments in the previous debate can look it up on Google. AFAICR it
involved the fclose() function.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"The question of copying music from the Internet is like a two-barreled sword."
- Finnish rap artist Ezkimo

[Mike Silva]

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message news:<3F**************@jpl.nasa.gov>...

Fao, Sean wrote:

A guy at http://www.embedded.com gave his opinion on the C language
and I was shocked to see the number of supporters for the author.
I also find it hard to believe that 99% of all code has memory leaks;
but, I suppose I could be wrong.

See what you think:

http://www.embedded.com

Take a look at

http://www.ganssle.com/bio.htm

Evidently, Jack Ganssle makes his living by lecturing and writing
articles and books on embedded computing.
He doesn't appear to have any other credentials
in embedded computing or in C programming.

You mean other than designing, building, programming and consulting on
embedded systems since the days of the 8008? You mean other than
(from the bio link you posted):

"He started, developed and sold three electronics companies; including
one of the world's leading producers of embedded development tools.

He developed or managed the development of over 100 embedded products,
including in-circuit emulators, underwater navigation equipment (some
used to recover Challenger's wreckage), steel thickness gauges,
near-IR protein measurement instruments, the White House security
system, compilers, colorimeters, numerous classified Government
systems... and even one device that analyzed cow poop!"