NotNull pointers

Steven Schveighoffer schveiguy at yahoo.com
Wed Aug 31 14:18:33 PDT 2011


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

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

You said there was a patch...?  Was it not complete?

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

Again, starting a debugger because you *know* an assert/segfault is about  
to occur is vastly different than diagnosing an *unexpected* assert in the  
field or on a machine that has no debugger.  Not all seg faults occur in  
tightly controlled scenarios.  Please stop suggesting debuggers are the  
only tool we should be using, it's just not always possible in the real  
world.  Otherwise, why have logging, stack traces, etc.

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

And that leaves in all bounds checking and every method call on any object  
calls the invariant (whether the derived object defines an invariant or  
not) without inlining.  Let me know who these people are so I never use  
their products!

There are much better tools for this, e.g. enforce.

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

I think that:

1. this is likely a combination of code generation issues in dmd and  
proliferation of asserts with templates/inlining as you say (I still feel  
there is something wrong with dmd, but I have no evidence).
2. Are more than 10% of those 7500 asserts of object references?  I'd be  
surprised if that were true.

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

Bloat is something to be combated, yes.  I am still of the school of  
thought that smaller exes are much better than bloatier ones, even when we  
have oodles of memory at our disposal.

But we are talking about *debug* builds.  I don't think your "people like  
to ship code compiled in non-release mode" argument holds water like a  
strainer.  And I think people *expect* bloat when they enable debugging  
information.  15 extra bytes per assert is nothing.

writeln adds 500k of "bloat".  Do people who use console output debugging  
(a.k.a. printf debugging) complain about bloat because they added in  
writeln?  I know I don't, and that's my main form of debugging.

-Steve


More information about the Digitalmars-d mailing list