NotNull pointers

Walter Bright newshound2 at digitalmars.com
Wed Aug 31 13:54:50 PDT 2011


On 8/31/2011 1:19 PM, Steven Schveighoffer wrote:
>> It's also possible for the program to have its own seg fault handler that
>> reads its own symbolic debug info and generates a line number and stack trace.
>> There was a patch to Phobos that did this a while back.
>
> This would also be a valid option. I have no idea why that wasn't included. Do you?

Nobody spent the time to do it, mainly because it takes a fairly advanced low 
level Windows programmer to understand and do it correctly.


>> Optlink's register dump on a seg fault is not Windows' doing, it installs a
>> seg fault handler which does this.
>
> I predominantly use Linux, so Optlink/Windows tools really don't help. D is
> supposed to support all OSes not just be useful on Windows.

Sure. It's just that since debuggers work on Linux, there should be no technical 
reason why this cannot be made to work. Of course it will be very different code 
than for Windows, but the user wouldn't see that.



> On linux, the shell options are what determine whether the OS generates a core
> dump, and by default they are off. It also does not hook seg faults to start a
> debugger by default, it just says "Segmentation Fault" on the command line and
> gives you a prompt. Useless.
>
>> > So 4 instructions per assert of a class reference (which is arguably not
>> common) is a lot of bloat?
>>
>> 15 bytes. And yes, this stuff adds up surprisingly quickly, especially if
>> you're the type that wants to leave the asserts on even in release mode.
>
> How is this possible? I thought release mode removed asserts?

I misspoke. -release does remove the asserts, but some developers do not use 
-release because they wish to leave the asserts on in their release builds.


> Currently, the empty main() program is 256k. Add in writeln("hello, world") and
> it adds 500k. Even if I had 10,000 asserts in there for objects, that adds 150k.
>
> I think bloat can't possibly be a valid concern here.

You'd be surprised. I was surprised to discover that all the asserts in 
std.datetime caused the unittest build of phobos to exceed all available memory 
on my (old) FreeBSD box. (Jonathan used his own version of assert that uses more 
runtime memory, he's got like 7500 in there.) Minimizing the footprint of 
assert's reduces the resistance people have to using them.

Bloat can get to be a big problem if you're using templates, the templates 
contain asserts, and those templates get inlined.

People have regularly complained about the size of D binaries.


> Besides, you ignored my comment about how we can eliminate the bloat. Care to
> respond?

I haven't thought about it.


More information about the Digitalmars-d mailing list