View mode: basic / threaded / horizontal-split · Log in · Help
March 05, 2012
Re: dereferencing null
On Mon, Mar 05, 2012 at 06:12:43PM +0100, Andrej Mitrovic wrote:
[...]
> Also, I find your message signatures amusing. :P

I have a file of amusing quotes that I collected over the years from
various sources (including some not-so-funny ones I made up myself), and
a 1-line perl script hooked to my Mutt compose function that randomly
selects a quote and puts it on my signature line.  Once in a while it
can coincidentally pick a quote relevant to the actual discussion in the
message body, which makes it even funnier.


T

-- 
Laissez-faire is a French term commonly interpreted by Conservatives to
mean 'lazy fairy,' which is the belief that if governments are lazy
enough, the Good Fairy will come down from heaven and do all their work
for them.
March 05, 2012
Re: dereferencing null
"Walter Bright" <newshound2@digitalmars.com> wrote in message 
news:jj252v$15vf$1@digitalmars.com...
> On 3/4/2012 11:50 PM, Chad J wrote:
>> Problems:
>> - I have to rerun the program in a debugger to see the stack trace. This 
>> is a
>> slow workflow. It's a big improvement if the segfault is hard to find, 
>> but only
>> a small improvement if the segfault is easy to find. Very bad if I'm 
>> prototyping
>> experimental code and I have a bunch to go through.
>
> I don't get this at all. I find it trivial to run the program with a 
> debugger:
>
>   gdb foo
>   >run
>
> that's it.
>

Not all software is minimally-interactive CLI.

>> I'm pretty sure other languages like C# and Java get this right. Haven't 
>> used
>> those two in a while though. Haxe... totally got this right. Also 
>> Actionscript 3
>> by proxy. Hell, even Synergy/DE, the DIBOL (!!) derivative that I use at 
>> work,
>> /gets this right/. I get stacktraces for null dereferences in these 
>> languages.
>> It's /really/ convenient and useful. I consider D to be very backwards in 
>> this
>> regard.
>
> Notably, C and C++ do not do what you suggest.

So what? C and C++ suck ass. That's why D exists.
March 05, 2012
Re: dereferencing null
"Walter Bright" <newshound2@digitalmars.com> wrote in message 
news:jj32l2$1dk$1@digitalmars.com...
> On 3/5/2012 4:27 AM, Jacob Carlborg wrote:
>> On 2012-03-05 11:38, Walter Bright wrote:
>>> Notably, C and C++ do not do what you suggest.
>>
>> Just because C and C++ do something in a certain way doesn't make it a 
>> valid
>> reason to do the same thing in D.
>>
>> I think this is an argument we need to stop using immediately. It just 
>> shows
>> we're stuck in our ways, can't innovate and can't think for our self.
>
>
> Doing things differently than well established practice requires a strong 
> reason. There are often good reasons for that established practice that 
> aren't obvious.
>

Ok, then what's the strong reason for abandoning the practice here that's 
been well established by damn near everying other than C/C++?
March 05, 2012
Re: dereferencing null
On 2012-03-05 20:02, Walter Bright wrote:
> On 3/5/2012 4:27 AM, Jacob Carlborg wrote:
>> On 2012-03-05 11:38, Walter Bright wrote:
>>> Notably, C and C++ do not do what you suggest.
>>
>> Just because C and C++ do something in a certain way doesn't make it a
>> valid
>> reason to do the same thing in D.
>>
>> I think this is an argument we need to stop using immediately. It just
>> shows
>> we're stuck in our ways, can't innovate and can't think for our self.
>
>
> Doing things differently than well established practice requires a
> strong reason. There are often good reasons for that established
> practice that aren't obvious.

Yeah, C and C++ might not do what's suggested but basically all other 
languages do it.

-- 
/Jacob Carlborg
March 05, 2012
Re: dereferencing null
"Adam D. Ruppe" <destructionator@gmail.com> wrote in message 
news:ewuffoakafwmuybbzztb@forum.dlang.org...
> On Monday, 5 March 2012 at 03:24:32 UTC, Chad J wrote:
>> It's that I simply cannot expect users to run my code in a debugger.
>
> :) I'm lucky if I can get more from my users than
> "the site doesn't work"!
>

I *hate* those reports!!

But they get worse than that: Fairly soon after retaliating to a "Durr...It 
don't work!" email with a nice formal (and painfully friendly) explanation 
of how and why to give me useful reports (which he even acknowledged as 
being a good point), I got from the same damn person (ie *the top guy in 
charge of the project in question!*): "So-and-so person told me that one of 
*their* people told them that the site didn't work when they tried it last 
week." WHAT THE FUCKING FUCK?!?!?! Shit like that I'm inclined to just blame 
on user error. I mean, crap, with a report like that, how am I supposed to 
know they spelled the URL right or even had a fucking internet connection at 
all? Or even a damn computer.

I swear, as soon as a computer enters the picture, most people turn shit 
stupid (well, more stupid than usual): I can't imagine that *even these 
people* would go up to an auto mechanic as say "Driving to Detroit didn't 
work!" But that's exactly the crap I have to put up with. And then *I* have 
to (politely!) explain to these shitheads how to not be a moron...only to 
have them come back and pull the same shit two weeks later? Fuck, and people 
wonder why I hate humans.
March 05, 2012
Re: dereferencing null
"Walter Bright" <newshound2@digitalmars.com> wrote in message 
news:jiunst$qrm$1@digitalmars.com...
>
> 3. Intercepting and recovering from seg faults, div by 0, etc., all sounds 
> great on paper. In practice, it is almost always wrong. The only exception 
> (!) to the rule is when sandboxing a plugin (as you suggested).
>

The purpose of catching exceptions is to respond to a condition. Recovery is 
merely *one* such type of response.
March 05, 2012
Re: dereferencing null
On Mon, 05 Mar 2012 13:29:09 -0500, deadalnix <deadalnix@gmail.com> wrote:

> Le 05/03/2012 15:26, Steven Schveighoffer a écrit :
>> On Fri, 02 Mar 2012 10:19:13 -0500, deadalnix <deadalnix@gmail.com>  
>> wrote:
>>
>>> Le 02/03/2012 15:37, Jacob Carlborg a écrit :
>>>> Isn't it quite unsafe to throw an exception in a signal ?
>>
>> One does not need to throw an exception. Just print a stack trace. I've
>> advocated for this multiple times. I agree it costs nothing to
>> implement, and who cares about safety when the app is about to crash?!
>>
>>> The signal handler is called on top of the stack, but the information
>>> to retrieve the stack trace are system dependant. BTW, using lib like
>>> libsigsegv can help a lot to make it safe. It isn't safe ATM, but it
>>> is doable.
>>
>> libsigsegv is used to perform custom handling of page faults (e.g.
>> loading pages of memory from a database instead of the MMC). You do not
>> need libsigsegv to handle SEGV signals.
>>
>> -Steve
>
> No you don't, but if you want to know if you are facing a stackoverflow  
> or a null deference for exemple, this greatly help the implementation.

It's somewhat off the table with it's GPL license.  But even so, I don't  
see that it helps here, we are not looking to continue execution, just  
more information on the crash than "Segmentation Fault".

-Steve
March 05, 2012
Re: dereferencing null
Steven Schveighoffer wrote:
> On Mon, 05 Mar 2012 13:29:09 -0500, deadalnix <deadalnix@gmail.com> wrote:
> 
>> Le 05/03/2012 15:26, Steven Schveighoffer a écrit :
>>> On Fri, 02 Mar 2012 10:19:13 -0500, deadalnix <deadalnix@gmail.com>
>>> wrote:
>>>
>>>> Le 02/03/2012 15:37, Jacob Carlborg a écrit :
>>>>> Isn't it quite unsafe to throw an exception in a signal ?
>>>
>>> One does not need to throw an exception. Just print a stack trace. I've
>>> advocated for this multiple times. I agree it costs nothing to
>>> implement, and who cares about safety when the app is about to crash?!
>>>
>>>> The signal handler is called on top of the stack, but the information
>>>> to retrieve the stack trace are system dependant. BTW, using lib like
>>>> libsigsegv can help a lot to make it safe. It isn't safe ATM, but it
>>>> is doable.
>>>
>>> libsigsegv is used to perform custom handling of page faults (e.g.
>>> loading pages of memory from a database instead of the MMC). You do not
>>> need libsigsegv to handle SEGV signals.
>>>
>>> -Steve
>>
>> No you don't, but if you want to know if you are facing a
>> stackoverflow or a null deference for exemple, this greatly help the
>> implementation.
> 
> It's somewhat off the table with it's GPL license.  But even so, I don't
> see that it helps here, we are not looking to continue execution, just
> more information on the crash than "Segmentation Fault".
> 
	I wonder if deadalnix isn't confusing with libSegFault which is
part of GNU's glibc: http://blog.andrew.net.au/2007/08/15/

		Jerome

PS: Sorry if this message is sent twice, there was an error the
first time and it looks like it didn't get through...
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr
March 05, 2012
Re: dereferencing null
On Mon, 05 Mar 2012 05:38:20 -0500, Walter Bright  
<newshound2@digitalmars.com> wrote:

> On 3/4/2012 11:50 PM, Chad J wrote:
>> Problems:
>> - I have to rerun the program in a debugger to see the stack trace.  
>> This is a
>> slow workflow. It's a big improvement if the segfault is hard to find,  
>> but only
>> a small improvement if the segfault is easy to find. Very bad if I'm  
>> prototyping
>> experimental code and I have a bunch to go through.
>
> I don't get this at all. I find it trivial to run the program with a  
> debugger:
>
>    gdb foo
>    >run
>
> that's it.

This argument continually irks me to no end.  It seems like the trusty  
(rusty?) sword you always pull out when defending the current behavior,  
but it falls flat on its face when a programmer is faced with a Seg Fault  
that has occurred on a program that was running for several days/weeks,  
possibly not in his development environment, and now he must run it via a  
debugger to wait another several days/weeks to (hopefully) get the same  
error.

Please stop using this argument, it's only valid on trivial bugs that  
crash immediately during development.

I wholeheartedly agree that we should use the hardware features that we  
are given, and that NullPointerException is not worth the bloat.  But we  
should be doing *something* better than just printing "Segmentation Fault".

-Steve
March 05, 2012
Re: dereferencing null
On Mon, Mar 05, 2012 at 05:31:34PM -0500, Steven Schveighoffer wrote:
[...]
> I wholeheartedly agree that we should use the hardware features that
> we are given, and that NullPointerException is not worth the bloat.
> But we should be doing *something* better than just printing
> "Segmentation Fault".
[...]

On Linux, you can catch SIGSEGV and print a stacktrace in the signal
handler. This is pretty standard procedure.

In theory, we *could* have druntime install a handler for SIGSEGV upon
program startup that prints a stacktrace and exits (or do whatever the
equivalent is on Windows, if compiled on Windows).


T

-- 
Let's eat some disquits while we format the biskettes.
4 5 6 7 8 9 10 11 12
Top | Discussion index | About this forum | D home