On Sunday, 19 May 2013 at 20:03:24 UTC, Andrei Alexandrescu wrote:
> You are blowing it out of proportion. Null references are hardly even on the radar of the bug classes I'm encountering in the style of programming of the three groups I worked in at Facebook, and also my previous employers. People I meet at conferences and consulting gigs never mention null references as a real problem, although I very often ask about problems. I find it difficult to agree with you just to be nice.

Just because people don't mention them as a problem doesn't mean it isn't a problem.

For what it's worth, null pointers are a real problem in the code I work on (games). I don't know exactly what you work on, but I find that they are more of a problem in highly stateful, interactive applications. Things like generic libraries, utility programs, compilers, etc. probably won't see the same problems because they aren't very stateful or interactive.

In my experience, null pointers are easy to fix, but the risk of them causes people to litter their code with if (ptr) tests, often with poor handling of the failure case, which can cause subtle bugs (no crash, but unintended code path).

Just my 2c.

On 5/19/2013 1:08 PM, Mr. Anonymous wrote:
> On Sunday, 19 May 2013 at 20:03:24 UTC, Andrei Alexandrescu wrote:
>> Well you got to do what you got to do. Field accesses for objects larger than
>> 4KB would have to be checked in @safe code.
>
> Isn't the solution as easy as doing:
> OR PTR:[address], 0
> the same way it's done for the stack?
>
> The offset it known at compile time in most cases, so the command would be
> required only if both:
> * The object is larger than target OS' guard page size.
> * The position is greater than target OS' guard page size, OR is unknown at
> compile time.

Not a bad idea.

On 5/19/2013 1:06 PM, Andrei Alexandrescu wrote:
> On 5/19/13 3:58 PM, Timon Gehr wrote:
>> (It is a talk.)
>
> (I read a transcript.)

I wish more talks had transcripts available. I can read an hour talk presentation in 5 minutes.

On 5/19/2013 1:03 PM, Maxim Fomin wrote:
> I think there is difference between catching exception and saving
> data which you have typed for some period and letting harware
> "check" the exception for you meanwile loosing your work.

You can catch seg faults. It's easier on Windows, but it's doable on Linux.

On 5/19/2013 11:22 AM, deadalnix wrote:
> The damn thing should have been initialized in the
> first place to avoid the bug.

Sounds like you have the double-checked locking bug. Using a different value to initialize it won't fix it.

If you have a global value accessible from multiple threads, you must use synchronization. There is no way around that. If you use some other global state to check for initialization in order to avoid synchronization, you have the double checked locking bug. Yes, you do.

On 5/19/2013 2:02 PM, Walter Bright wrote:
> If you have a global value accessible from multiple threads, you must use
> synchronization. There is no way around that. If you use some other global state
> to check for initialization in order to avoid synchronization, you have the
> double checked locking bug. Yes, you do.


BTW, a few years ago, I presented my clever solution to the double checked locking bug to Scott Meyers. I was very proud of it. Scott handed me my @ss (in a nice way), but I got my comeuppance.

It reminded me of the hours I spent in high school determined to show that I could trisect an angle with a compass and a straightedge. There was always some tiny flaw :-)

On 5/19/13 4:30 PM, Peter Alexander wrote:
> On Sunday, 19 May 2013 at 20:03:24 UTC, Andrei Alexandrescu wrote:
>> You are blowing it out of proportion. Null references are hardly even
>> on the radar of the bug classes I'm encountering in the style of
>> programming of the three groups I worked in at Facebook, and also my
>> previous employers. People I meet at conferences and consulting gigs
>> never mention null references as a real problem, although I very often
>> ask about problems. I find it difficult to agree with you just to be
>> nice.
>
> Just because people don't mention them as a problem doesn't mean it
> isn't a problem.
>
> For what it's worth, null pointers are a real problem in the code I work
> on (games). I don't know exactly what you work on, but I find that they
> are more of a problem in highly stateful, interactive applications.
> Things like generic libraries, utility programs, compilers, etc.
> probably won't see the same problems because they aren't very stateful
> or interactive.
>
> In my experience, null pointers are easy to fix, but the risk of them
> causes people to litter their code with if (ptr) tests, often with poor
> handling of the failure case, which can cause subtle bugs (no crash, but
> unintended code path).
>
> Just my 2c.

OK, this is sensible. One question - would you be willing to type symbols as NullType!T instead of T to avoid these issues?

Thanks,

Andrei

On Sunday, 19 May 2013 at 20:03:24 UTC, Andrei Alexandrescu wrote:
> On 5/19/13 3:36 PM, deadalnix wrote:
>> On Sunday, 19 May 2013 at 19:10:28 UTC, Andrei Alexandrescu wrote:
>>> No, your argument is ridiculous. You make a yarn with precious little
>>> detail that describes for everything everyone knows a textbook race
>>> condition, essentially ask that you are taking by your word that
>>> non-null would miraculously solve it, and, to add insult to injury,
>>> and when we don't buy it, you put the burden of proof on us. This is
>>> quite a trick, my hat is off to you.
>>>
>>
>> I described a very usual null bug : something is set to null, then to a
>> specific value. It is assumed not to be null. In a specific case it is
>> null and everything explode.
>>
>> The concurrent context here made it especially hard to debug, but isn't
>> the cause of the bug.
>>
>> Additionally, if you don't have enough information to understand what
>> I'm saying, you are perfectly allowed to ask for additional details This
>> isn't a shame.
>
> Your argument has been destroyed so no need to ask details about it. Replace "null" with "invalid state" and it's the same race in any system. Let's move on.
>

"I don't want t to understand because I know I'm right. The fact you solved that issue and I didn't is irrelevant, I know better."

> You are blowing it out of proportion. Null references are hardly even on the radar of the bug classes I'm encountering in the style of programming of the three groups I worked in at Facebook, and also my previous employers. People I meet at conferences and consulting gigs never mention null references as a real problem, although I very often ask about problems. I find it difficult to agree with you just to be nice.
>

Hiphop type annotations are non null by default. Just saying.

On Sunday, 19 May 2013 at 21:02:57 UTC, Walter Bright wrote:
> On 5/19/2013 11:22 AM, deadalnix wrote:
>> The damn thing should have been initialized in the
>> first place to avoid the bug.
>
> Sounds like you have the double-checked locking bug. Using a different value to initialize it won't fix it.
>

No it sound like initalizing something to null, then initialize it properly, assume all over the place that it is initialized to something else, and in some rare code path it blows up.

The fact that this occurs in a multithreaded environment made it super hard to debug, but the whole thing was properly synchronized.

Don't assume that I do not understand what the problem with double check locking is : http://d.puremagic.com/issues/show_bug.cgi?id=6607

On Sunday, 19 May 2013 at 20:30:28 UTC, Peter Alexander wrote:
> On Sunday, 19 May 2013 at 20:03:24 UTC, Andrei Alexandrescu wrote:
>> You are blowing it out of proportion. Null references are hardly even on the radar of the bug classes I'm encountering in the style of programming of the three groups I worked in at Facebook, and also my previous employers. People I meet at conferences and consulting gigs never mention null references as a real problem, although I very often ask about problems. I find it difficult to agree with you just to be nice.
>
> Just because people don't mention them as a problem doesn't mean it isn't a problem.
>
> For what it's worth, null pointers are a real problem in the code I work on (games). I don't know exactly what you work on, but I find that they are more of a problem in highly stateful, interactive applications. Things like generic libraries, utility programs, compilers, etc. probably won't see the same problems because they aren't very stateful or interactive.
>
> In my experience, null pointers are easy to fix, but the risk of them causes people to litter their code with if (ptr) tests, often with poor handling of the failure case, which can cause subtle bugs (no crash, but unintended code path).
>
> Just my 2c.

Exactly !

Most of time null issue are easy to solve and is just the kind of crap that slow you down, and once in a while this ends up being an horrible mess.

It is also true that rare path are often badly tested (and sometime you have no clue if the thing can be null or not, so you don't even know how to test it). Same argument Walter like to make about very rare failure cases apply here.