Re: Denial of denial of service

[prev] [thread] [next] [lurker] [Date index for 2007/01/29]

From: Yossi Kreinin
Subject: Re: Denial of denial of service
Date: 12:23 on 29 Jan 2007
Joshua Rodman wrote:
> On Mon, Jan 29, 2007 at 11:13:35AM +0200, Yossi Kreinin wrote:
> 
> Of cousrse, I dont' believe this amount of overhead matters to most
> people at all anymore.  But I know in some circumstances it is
> completely unacceptable.

Sure, I use exceptions in desktop applications because I don't care about the 
overhead there.

> 
> What is a real pisser is that you claim you have to manually tell the
> compiler to turn it off globally.  If you don't use the exceptions
> feature in any of your code, can't the compiler figure out to make this
> optimization?  

A lot of horror related to C/C++ implementation/instrumentation comes from the 
fact that in practice, your source code must be built to interact with code 
built by someone else. For example, you might want to compile your application 
with padding of uninitialized memory between structure members so that something 
like valgrind has more chances to spot buffer overflows (a random example - the 
first thing that came to mind). You can't do that since calls to functions built 
by someone else or written in assembly won't work. This is why things like 
garbage collection remain theoretical.

The same is true for exceptions - you never know if a function built by someone 
else throws one, so you must be prepared for stack unwinding.

Another horrible thing about C++ is that the calling conventions are not 
portable across compilers (C conventions largely are). The different mangling 
conventions of different compilers you can work around using extern "C". But 
different stack unwinding conventions you can not work around that easily.

That aside, C/C++ compilers rarely do anything at all at link time - they emit 
assembly code and walk away and the linker links it without knowing anything 
about C/C++. The linker doesn't know about exceptions so it can't make decisions 
depending on whether some of the code throws something or not, even if it does 
see all relevant code (no dynamic loading, etc.)

Of course a lot of these problems are hard to solve. LLVM is one serious attempt 
- it stores bytecode in portable IR and can do just-in-time compilations, hairy 
link-time things (I think gcc 4 is strong there, too), etc. But most C/C++ 
platforms are simpler than that, and the big problem is having to assume the 
lowest common denominator. One great thing about JVM, .NET, etc. is that you can 
analyze & instrument code built by someone else. Of course when C was designed 
such approach wasn't very practical even without JITting - you wouldn't like to 
spend time on first compiling code to IR and then compile the IR to native bytecode.

The thing is that in C there's a much smaller gap between theory and practice. 
In C++, templates are theoretically much better than macros, in practice they 
take ages to compile. Overloading is theoertically wonderful because it gives 
you compile-time polymorhpism and what-not, in practice go figure who calls what 
(grep won't work and IDEs won't either), and there's no portable mangling 
convention (how hard would that be?). Exceptions are theoretically 
zero-overhead, in practice again no portable unwinding conventions, and huge 
data overhead and almost always small run-time overhead, and once an exception 
is thrown you lose the call stack, and, and, and...

> 
> So long as you stop caring about performance nearly entirely, I think
> there are many such platforms available.
> 

In these cases the first thing I do is choose a different language, one that is 
willing to at least try not to dump core.
There's stuff above here

Generated at 23:01 on 06 Feb 2007 by mariachi 0.52