"Walter Bright" <newshound1@digitalmars.com> wrote in message news:hkv1mg$s6e$1@digitalmars.com...
> retard wrote:
>> Tue, 09 Feb 2010 18:49:31 -0800, Walter Bright wrote:
>>
>>> D has moved a lot towards supplying by default a lot of what Coverity claims to do. By making such an expensive tool irrelevant for D, we can make D much more cost effective.
>>
>> D doesn't provide non-nullable types
>
> Yes, there have been a couple long threads about that. Dereferencing a null pointer is a bug, but not a security/safety issue.
>

Right, it's just not worthwhile for a language to provide help avoiding bugs.

Wed, 10 Feb 2010 15:29:06 -0500, Nick Sabalausky wrote:

> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:hkv1mg$s6e$1@digitalmars.com...
>> retard wrote:
>>> Tue, 09 Feb 2010 18:49:31 -0800, Walter Bright wrote:
>>>
>>>> D has moved a lot towards supplying by default a lot of what Coverity claims to do. By making such an expensive tool irrelevant for D, we can make D much more cost effective.
>>>
>>> D doesn't provide non-nullable types
>>
>> Yes, there have been a couple long threads about that. Dereferencing a null pointer is a bug, but not a security/safety issue.
>>
>>
> Right, it's just not worthwhile for a language to provide help avoiding bugs.

Having such a language would cause unemployment among expensive professional programmers. Thus not worth it. That's why non-nullable types aren't even worth a try in an experimental branch of dmd unlike 1000 times more useful features like built-in compiler support for regular expressions, opFish or having an integrated email client.

Nick Sabalausky wrote:
> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:hkv1mg$s6e$1@digitalmars.com...
>> retard wrote:
>>> Tue, 09 Feb 2010 18:49:31 -0800, Walter Bright wrote:
>>>
>>>> D has moved a lot towards supplying by default a lot of what Coverity
>>>> claims to do. By making such an expensive tool irrelevant for D, we can
>>>> make D much more cost effective.
>>> D doesn't provide non-nullable types
>> Yes, there have been a couple long threads about that. Dereferencing a null pointer is a bug, but not a security/safety issue.
>>
> 
> Right, it's just not worthwhile for a language to provide help avoiding bugs. 


It's a benefit/cost issue. There are no bug-preventing features that are without cost, the idea is to maximize the ratio.

"retard" <re@tard.com.invalid> wrote in message news:hkv5op$s4n$1@digitalmars.com...
> Wed, 10 Feb 2010 15:29:06 -0500, Nick Sabalausky wrote:
>
>> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:hkv1mg$s6e$1@digitalmars.com...
>>>
>>> Yes, there have been a couple long threads about that. Dereferencing a null pointer is a bug, but not a security/safety issue.
>>>
>>>
>> Right, it's just not worthwhile for a language to provide help avoiding bugs.
>
> Having such a language would cause unemployment among expensive professional programmers. Thus not worth it. That's why non-nullable types aren't even worth a try in an experimental branch of dmd unlike 1000 times more useful features like built-in compiler support for regular expressions, opFish or having an integrated email client.

opFish!!! Yes, I want it! :)

Although that would beg the question of what would be the appropriate way to express gratitude for it if it were to get implemented:

Option 1: Thanks for op the fish!
Option 2: Thanks for all the opFish!
Option 30: Icehouse (<--- Ok, that joke's probably *really* obscure)

Walter Bright:

[about non-nullable types]
> It's a benefit/cost issue. There are no bug-preventing features that are without cost, the idea is to maximize the ratio.

It surely has a cost (you can see it in the Cyclone language: it's safe but quite fussy, so the costs for the programmer can be high enough to discourage its use), but I have not tried this feature in other languages, so it's not easy for me to measure its costs :-)

Bye,
bearophile

Wed, 10 Feb 2010 12:47:41 -0800, Walter Bright wrote:

> Nick Sabalausky wrote:
>> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:hkv1mg$s6e$1@digitalmars.com...
>>> retard wrote:
>>>> Tue, 09 Feb 2010 18:49:31 -0800, Walter Bright wrote:
>>>>
>>>>> D has moved a lot towards supplying by default a lot of what Coverity claims to do. By making such an expensive tool irrelevant for D, we can make D much more cost effective.
>>>> D doesn't provide non-nullable types
>>> Yes, there have been a couple long threads about that. Dereferencing a null pointer is a bug, but not a security/safety issue.
>>>
>>>
>> Right, it's just not worthwhile for a language to provide help avoiding bugs.
> 
> 
> It's a benefit/cost issue. There are no bug-preventing features that are without cost, the idea is to maximize the ratio.

What exactly is the cost here? The non-nullability invariant can be checked on compile time. It incurs no runtime overhead. Also the notation can be quite terse, as we have seen in Other Languages(tm).

Walter Bright, el 10 de febrero a las 11:33 me escribiste:
> retard wrote:
> >Tue, 09 Feb 2010 18:49:31 -0800, Walter Bright wrote:
> >
> >>D has moved a lot towards supplying by default a lot of what Coverity claims to do. By making such an expensive tool irrelevant for D, we can make D much more cost effective.
> >
> >D doesn't provide non-nullable types
> 
> Yes, there have been a couple long threads about that. Dereferencing a null pointer is a bug, but not a security/safety issue.

What about 3677?

Quote:
--------------------------------
This supposedly "safe" program under Mac OS X 10.6 doesn't give any error neither at compile time nor at runtime, yet it isn't memory-safe at all as it corrupts some part of the memory space.

struct S {
    uint[100000] a;
    uint b;
}

S* s = null;

@safe void main() {
    s.b = 1;
}

This happen because the offset for member "b" is very far, allowing it to falls on another memory page which happen to exists.
--------------------------------

http://d.puremagic.com/issues/show_bug.cgi?id=3677

It's a strange case, I know...

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------

Leandro Lucarella wrote:
> This supposedly "safe" program under Mac OS X 10.6 doesn't give any error
> neither at compile time nor at runtime, yet it isn't memory-safe at all as
> it corrupts some part of the memory space.


@safe is in its infancy, and I expect there to be some gaps. We'll get them plugged over time. In the meantime, it's great that you filed a bug report on it.

retard wrote:
> What exactly is the cost here? The non-nullability invariant can be checked on compile time. It incurs no runtime overhead. Also the notation can be quite terse, as we have seen in Other Languages(tm).

If you want, you can create a template NonNullable that wraps an existing type, and try that out.

On 2010-02-10 17:29:09 -0500, Walter Bright <newshound1@digitalmars.com> said:

> retard wrote:
>> What exactly is the cost here? The non-nullability invariant can be checked on compile time. It incurs no runtime overhead. Also the notation can be quite terse, as we have seen in Other Languages(tm).
> 
> If you want, you can create a template NonNullable that wraps an existing type, and try that out.

Just did that yesterday. It's probably not what most people expect though: it doesn't do static checking. But at least it catches null assignments early, before the null value breaks something elsewhere in the program. For your enjoyment:

/**
Struct to make object references and pointers unable to accept a null value.
The initial value is still null, but after the first assignment the value can
never become null again. Attempting to assign null will throw an
IllegalNullAssignment error.
*/
struct NonNullable(T) {
	private T _nonNullableValue;
	alias _getNonNullableValue this;
	
	this(T value) {
		opAssign(value);
	}
	this(NonNullable!T value) {
		// FIXME: Not polymorphic
		opAssign(value);
	}
	
	void opAssign(V, string file = __FILE__, int line = __LINE__)(V newValue) {
		if (isNull(newValue))
			IllegalNullAssignment.bailOut(file, line, "Attempt to assign null to "
										  "non-nullable " ~ T.stringof ~ ".");
		_nonNullableValue = newValue;
	}
	
	T _getNonNullableValue() {
		assert(_nonNullableValue, "Attempt to access uninitialized non-nullable " ~ T.stringof ~ ".");
		return _nonNullableValue;
	}
	
	private {
		bool isNull(T)(T value) if (__traits(compiles, value._nonNullableValue)) {
			return isNull(value._nonNullableValue);
		}
		bool isNull(T)(T value) if (__traits(compiles, value is null)) {
			return value is null;
		}
	}
}


/**
Error thrown when attempting to assign a null value to a non-nullable.
*/
class IllegalNullAssignment : Error {
	this(string message) {
		super(message);
	}
	
	private static void bailOut(string file, int line, in char[] msg) {
		throw new IllegalNullAssignment(text(file, '(', line, "): ", msg));
	}
}


unittest {
	NonNullable!Object o;
	NonNullable!ClassInfo o2 = o.classinfo;
	NonNullable!TypeInfo o3;
	//NonNullable!Object o4 = o2; // FIXME: polymorphic NonNullable
	o = new Object;
	o = o2;
	try {
		o = o3; // should throw
		o.toString();
		assert(0, "prior assignment should have thrown");
	} catch (IllegalNullAssignment e) {
		// ok, error thrown.
	}
}



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