An Authors View on C

J

Joe Wright

Kevin said:
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. :)
 
G

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
 
E

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

Joe Wright

Jirka said:
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?
 
D

Dan Pop

In said:
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
 
D

Dan Pop

In said:
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
 
C

Christopher Benson-Manica

Dan Pop said:
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" );
 
M

Mike Wahler

Ed Morton said:
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

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

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

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
 
A

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
 
D

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
 
J

Joe Wright

Arthur said:
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.
 
C

Christopher Benson-Manica

Dan Pop said:
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. ;)
 
J

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

Dan Pop

In said:
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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top