An Authors View on C

[Kevin D. Quitt]

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

My .sig for over 20 years:

 

[Joe Wright]

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.

 

[Jirka Klaue]

What do you suppose those commas will do?

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

Jirka

 

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

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]

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?

 

[Dan Pop]

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]

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

 

[Christopher Benson-Manica]

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" );

 

[Mike Wahler]

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

 

[E. Robert Tisdale]

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]

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.

 

[Arthur J. O'Dwyer]

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]

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]

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

 

[Joe Wright]

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

Ok, I got it. ',' lower than '=='. Sorry for the noise.

 

[Dan Pop]

Does undefined behavior count?

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

Dan

 

[Christopher Benson-Manica]

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.

 

[Joona I Palaste]

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

 

[Dan Pop]

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