On 2014-01-04 14:46:26 +0000, "Adam D. Ruppe" <destructionator@gmail.com> said:

> On Saturday, 4 January 2014 at 12:37:34 UTC, ilya-stromberg wrote:
>> Have you got any plans to impove this situation?
> 
> I wrote a NotNull struct for phobos that could catch that situation. I don't think it got pulled though.
> 
> http://arsdnet.net/dcode/notnull.d
> 
> With @disable is becomes reasonably possible to restrict built in types with wrapper structs. It isn't perfect but it isn't awful either.
> 
> The big thing people have asked for before is
> 
> Object foo;
> if(auto obj = checkNull(foo)) {
>     obj == NotNull!Object
> } else {
>    // foo is null
> }
> 
> and i haven't figured that out yet...

In my nice little C++ world where I'm abusing macros and for loops:

	#define IF_VALID(a) \
		if (auto __tmp_##a = a) \
			for (auto a = make_valid_ptr(__tmp_##a); __tmp_##a; __tmp_##a = nullptr)

Usage:

	T * ptr = ...something...;

	IF_VALID (ptr)
	{
		... here ptr is of type ValidPtr< T > which can't be null
		... can be passed to functions that wants a ValidPtr< T >
	}
	else
	{
		... here ptr is of type T*
	}

Can't do that in D.

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca

On 1/3/14 6:09 PM, NoUseForAName wrote:
> This piece (recently seen on the Hacker News front page):
>
> http://rust-class.org/pages/using-rust-for-an-undergraduate-os-course.html
>
> .. includes a pretty damning assessment of D as "unsafe" (compared to
> Rust) and generally doomed. I remember hearing Walter Bright talking a
> lot about "safe code" during a D presentation. Was that about a
> different kind of safety? Is the author just wrong? Basically I want to
> hear the counterargument (if there is one).

This thread is very interesting - I posted a link to it to the reddit discussion: http://www.reddit.com/r/programming/comments/1ucvtd/using_rust_for_an_undergraduate_os_course/ceh5ysq

Andrei

On Saturday, 4 January 2014 at 13:49:40 UTC, Timon Gehr wrote:
> On 01/04/2014 06:16 AM, Walter Bright wrote:
>> On 1/3/2014 8:36 PM, Timon Gehr wrote:
>>> On 01/04/2014 05:31 AM, Walter Bright wrote:
>>>> ...
>>>>
>>>> Null pointers are not a safety issue.
>>>
>>> In the general sense of the word, yes they are.
>>
>> Please explain.
>>
>
> Safety is some kind of guarantee that something bad never happens.
>
> Eg. memory safety guarantees that memory never gets corrupted and null safety guarantees that null pointers never get dereferenced. Any property that can be stated in this way is a safety property.
>
> Hence it is fine to claim that the lack of dereferenceable null pointers makes a language safer, even though it has no bearing on memory safety.

Amen

On Saturday, 4 January 2014 at 04:20:30 UTC, David Nadlinger wrote:
> This is not true. While it _is_ possible to get null pointers in @safe code, they are not a safety problem, as the first page is never mapped in any D processes (yes, I'm aware of the subtle issues w.r.t. object size here, c.f. Bugzilla). And if you find a way to obtain a dangling pointer in @safe code, please report it to the bug tracker, this is not supposed to happen.

What happens when you have an object/array/struct/whatever that is larger than a page, and access one of the members/indices that is more than one page-size away from the starting point? Wouldn't this cause memory corrupting if the second page is mapped and you have a NULL pointer?

On Saturday, 4 January 2014 at 04:20:30 UTC, David Nadlinger wrote:
> On Saturday, 4 January 2014 at 02:27:24 UTC, Kelet wrote:
>> While `@safe` helps reduce this class of logic errors […]
>> you can still have […] dangling pointers, hence it is
>> usually considered inferior with regards to safety.
>
> This is not true. While it _is_ possible to get null pointers in @safe code, they are not a safety problem, as the first page is never mapped in any D processes (yes, I'm aware of the subtle issues w.r.t. object size here, c.f. Bugzilla). And if you find a way to obtain a dangling pointer in @safe code, please report it to the bug tracker, this is not supposed to happen.
>
> Cheers,
> David

There are many examples when one can get dangling pointer in @safe code, they are fixed slowly, almost never (like slicing static array - it was in bugzilla for some time and still not fixed AFAIK, let alone other issues which received zero response). By the way, asking to post such examples to bugzilla contradicts idea that it is impossible to have such kind of code. And being in bugzilla is not excuse for these bugs.

On Sat, Jan 04, 2014 at 12:10:20AM -0800, Walter Bright wrote:
> On 1/3/2014 11:42 PM, ilya-stromberg wrote:
> >NULL pointer means that I don't have any valid object, and it's good situation.  But there are a lot of situations when function must take a valid object (at least NOT NULL pointer). D allows:
> >
> >1) use `if(p is null)` and than throw exception - it will be safe,
> >but I have additional `if` check
> >2) ues `assert(p !is null)` - theoretically, it will be safe, but
> >program can have different situation is realise mode and fails (for
> >example, because nobody provide the same example in debug mode)
> >3) do nothing - programmer just forgot to add any checks
> >
> >Also, I must to add unit tests for every posible case usage of that function with a valid object. So, it's kind of dynamic typing that can be done by compiler type system.
> >
> >So, in a few cases null pointers are a safety issue.
> 
> I believe this is a misunderstanding of what safety is. It means memory safety - i.e. no memory corruption. It does not mean "no bugs".
> 
> Memory corruption happens when you've got a pointer to garbage, and then you read/write that garbage.
> 
> Null pointers seg fault when they are dereferenced, halting your program. While a programming bug, it is not a safety issue.

Keep in mind, though, that for sufficiently large objects, null pointers may not segfault (e.g., when you dereference a field at the end of the object, which, when large enough, will have a sufficiently large address to not cause a segfault when the base pointer is null -- you *will* end up with memory corruption in that case).


T

-- 
In theory, software is implemented according to the design that has been carefully worked out beforehand. In practice, design documents are written after the fact to describe the sorry mess that has gone on before.

On 01/04/2014 03:46 PM, Adam D. Ruppe wrote:
> On Saturday, 4 January 2014 at 12:37:34 UTC, ilya-stromberg wrote:
>> Have you got any plans to impove this situation?
>
> I wrote a NotNull struct for phobos that could catch that situation. I
> don't think it got pulled though.
>
> http://arsdnet.net/dcode/notnull.d
>
> With @disable is becomes reasonably possible to restrict built in types
> with wrapper structs. It isn't perfect but it isn't awful either.
> ...

This mechanism would be more useful if moving was specified to occur whenever provably possible using live variable analysis.

Currently it is impossible to implement even a type analogous to rusts ~T type, a unique reference (without a non-dereferenceable state.)

> The big thing people have asked for before is
>
> Object foo;
> if(auto obj = checkNull(foo)) {
>     obj == NotNull!Object
> } else {
>    // foo is null
> }
>
> and i haven't figured that out yet...

I think it is impossible to do, because the boolean value tested must be computable from the result of checkNull, which must be a variable of type NotNull!Object, which does not have a state for null.

The following is possible:

auto checkNull(alias notnull, alias isnull,T)(T arg) /+if(...)+/{
    return arg !is null ? notnull(assumeNotNull(arg)) : isnull();
}

Object foo;

foo.checkNull!(
    obj => ... /* is(typeof(obj)==NotNull!Object) */,
    ()  => ... /* foo is null */,
)

On 1/4/2014 9:40 AM, H. S. Teoh wrote:
> Keep in mind, though, that for sufficiently large objects, null pointers
> may not segfault (e.g., when you dereference a field at the end of the
> object, which, when large enough, will have a sufficiently large address
> to not cause a segfault when the base pointer is null -- you *will* end
> up with memory corruption in that case).

Yes, that was already mentioned.

On 1/4/2014 1:18 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> I don't disagree, but isn't that just a special case of type constraints? Why
> limit it arbitrarily to null-values, limiting the range of values is useful for
> ints and floats too. If you move the constraint check to the function caller you
> can avoid testing when it isn't needed.

Yes, the non-NULL thing is just one example of a useful constraint one can put on types.

On 1/4/2014 5:49 AM, Timon Gehr wrote:
> Hence it is fine to claim that the lack of dereferenceable null pointers makes a
> language safer, even though it has no bearing on memory safety.

I believe it is misusing the term by conflating safety with bug-free.