NotNull pointers

[Steven Schveighoffer]

On Wed, 31 Aug 2011 16:02:56 -0400, Walter Bright  
<newshound2 at digitalmars.com> wrote:

> On 8/31/2011 4:46 AM, Steven Schveighoffer wrote:
>> Seg faults are not as useful as asserts. It's a fact.
>
> You might be surprised, then, that I'll often temporarily replace an  
> assert with a HLT instruction so I can use a debugger on it :-)

Not at all.  If you prefer that mode of debugging, that's fine.  But if I  
have 150 systems running a program I wrote, and one of them fails every  
week (random which one, and length of time), you'd better bet I'm going to  
prefer a stack trace to a seg fault.  I don't want to wait another week +  
install debuggers on each of those systems.

When I said Seg faults are not as useful as asserts, I meant *unplanned*  
seg faults.  If you plan for a seg fault to occur, (or even an assert) you  
can use a debugger to capture it.

>> If you have a seg fault,
>> you must reproduce the error while in a debugger, or generate a core  
>> dump.
>> Reproducing not be possible, or might take considerable time. Any  
>> argument
>> against this is revisionist history. Yes, if I go back in time and run  
>> it in a
>> debugger for that execution, it would be useful. Yes, if I go back in  
>> time and
>> change my shell options to generate a core dump, it would be useful. If  
>> you have
>> an assert, you get a stack trace, no need to reproduce the assert in a  
>> debugger,
>> or enable non-default settings in your shell. It just gives you the  
>> information
>> you need.
>
>
> 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?

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

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?

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.

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

-Steve