stack smashing Was: Re: Scanning Formats (TIFF vs. JPEG)

[Josh Dersch]

Well, I seem to have struck a nerve here, now haven't I?  I was 
intending my comment to be mostly tongue-in-cheek, but I guess I failed 
on that count.  Next time I'll use more smileys.

> The problem is that in Java, you can get
> away with allocating gobs of memory without having to free it, and
> justify it with "Oh, the GC will clear it for me" however that attitude
> does not work when dealing with JDBC connections, or file handles. 
So your argument seems to be that the experience to know that JDBC and 
file handles are the exception to the rule is necessary here.   No 
argument there.  It's an unfortunate issue with the language (or it may 
be an unfortunate issue with the way the JDBC libraries are written). 
The same mistakes can be made in any other language that lacks a GC. 
> So, while you might be able to get away with writing sloppy memory
> allocation code in Java,
How does one write memory allocation code in Java?  As far as I know, 
there's really only one interface to it and it's provided by the 
runtime.  If you're talking about being wasteful with memory, that's one 
thing... but you can be wasteful with memory in any language with no 
skill involved.

> I pointed at C and assembly as examples of languages that lack garbage
> collection.  Because they lack this "feature", they therefore enforce
> writing of better code, or force you to face much earlier crashes,
> and/or a clear growth of memory footprint over time.
I posit that you can write crappy code in any language and still get 
away with it.  Hell, I'd say it's a lot easier to write crappy code in 
C.  The things I've seen done with pointers... ugh.  As for C 
_enforcing_ writing better code (solely due to lack of a GC?) -- you're 
kidding right?  It enforces _knowledgeable_ programmers to be 100 times 
more careful (and the key here is _knowledgeable_) , but it won't 
prevent _anyone_ from shooting themselves in the foot without even 
knowing it even if they think they are being careful (buffer overruns, 
invalid pointers, etc).  That's why this thead about stack-smashing got 
started in the first place, eons ago...
> With Java, the memory footprint climbs up and down over time as the GC
> is invoked, and if the GC has to do a lot of work, the JVM freezes, and
> many memory leaks you may have are masked by the GC.  You don't really
> know if you have a leak or not until it's too late (when you see your
> JVM has a 2GB footprint and is doing GC's that take over 60 seconds to
> complete), and even then, its difficult to locate it amongst several
> thousand threads.
I don't know about Java specifically, but I know that for C# there are 
profiling tools to help you nail down memory leaks when they occur.  I 
assume that these also exist for Java.   If you're looking for memory 
leaks solely based on memory footprint of the process, then yes, you're 
going to have problems.

> I do think that it is proper to blame every language for all of their
> shortcomings 
I agree with the sentiment, but I still disagree that "inexperienced 
programmers" is a shortcoming of the language.  I can see every 
programming language on earth falling into this bucket.
> - please do not pretend to hold some sort of high moral
> ground by claiming to uphold a language as some sort of godly
> perfection, while in the same breath, you have turned up your nose at
> the idea of writing threaded database connectivity drivers in "raw"
> assembly.
I have done no such thing.  I merely sought to point out a flaw in a 
proposition you made -- that it would be better to replace easily 
maintainable/portable (in the _right hands_) code written in a 
high-level language, dealing with high-level concepts (database access, 
multithreading) with hand-built assembly code.  And you propose doing 
this _only_ because it somehow magically causes people to make fewer 
mistakes with memory allocation.  I don't think this is a reasonable 
argument.  There is a place for assembly code, but I don't believe this 
particular case is one of them.  I'd also argue that one can make many 
more mistakes much more easily in assembly, even if one manages to 
allocate memory correctly. 

I think the argument you're really making here is that _experienced_ 
programmers (ones who have dealt with low-level languages like assembly 
and C) know the pitfalls of memory allocation, file handles, performance 
issues, etc... and as such could make much better use of Java.  What 
you're really saying is that you need to hire better programmers, and 
that some programmers need to be better educated in computer architecture.

> But don't fail to call out the flaws where you find
> them - even if they happen to be in a favored or popular language.
>   
I don't necessarily disagree.  All languages have issues.  What I 
disagree with is your earlier claim that rewriting code better suited 
for high-level languages in assembly is some sort of magic bullet that 
would somehow reduce programmer error.  If you gave the same Java coder 
who's borking up the JDBC connections the task to rewrite it in assembly 
I doubt very much that person would come up with an error-free 
implementation in a reasonable timeframe.  I think it would be far more 
productive to sit down with the coder, beat him with a LART and explain 
that JDBC and File handles need to be closed (and why!).

Josh