View mode: basic / threaded / horizontal-split · Log in · Help
November 06, 2010
Re: Spec#, nullables and more
Jesse Phillips, el  5 de noviembre a las 18:38 me escribiste:
> Leandro Lucarella Wrote:
> 
> > And then, you can corrupt memory with something like:
> > 
> > struct S {
> > 	int[1_000_000_000] data;
> > 	int far_data;
> > }
> > 
> > S* s = null;
> > s.far_data = 5;
> > 
> > If you are unlucky enough to end up in a valid address. That might not
> > be a practical example, of course, but theoretically null pointer could
> > lead to memory corruption.
> 
> Interesting, I get this:
> 
> test.d(13): Error: index 1000000000 overflow for static array
> 
> I'm not exactly sure what you are trying to demonstrate with it. Are
> you filling up the stack such that the OS tries to assign to a proper
> data field? How is it still not trying to access location 0 causing an
> Access Violation?

s.far_data = 5 is the same as *(s + S.far_data.sizeof) = 5, where
S.far_data.sizeof is 4_000_000_000 (i.e. 4 GB, I put a couple of extra
0 than I should :).

The point is, you're writing to a big address, which might be mapped to
your process, resulting in corrupted memory.

I think the error you are receiving is a compiler limitation, not
a language feature, but I might be wrong...

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Pa' ella cociné, pa' ella lavé, pa' ella soñe
Paella completa, $2,50
Pero, la luz mala me tira, y yo? yo soy ligero pa'l trote
La luz buena, está en el monte, allá voy, al horizonte
November 06, 2010
Re: Spec#, nullables and more
On 11/5/2010 10:27 AM, Don wrote:
> Pelle Månsson wrote:
>> On 11/05/2010 03:04 PM, Kagamin wrote:
>>> Pelle Månsson Wrote:
>>>
>>>> Getting the error early is actually a lot better than getting the error
>>>> late.
>>>
>>> OK, but it doesn't reduce the number of bugs. You had an error with
>>> nullables and you still has error with non-nullables.
>>
>> But in the non-nullable version you actually know where the bug is,
>> namely where you assign the null to the thing that shouldn't be null.
>> The segfault can come from any unrelated part of the program whereto
>> your null has slipped, at any later point in time.
> 
> I've always found it very easy to work out where a null came from. 

I hadn't. It really depends on what kind of code you're dealing with.
I've seen null-related bugs that took many, many hours to trace, because
the code was using several third-party libraries.

For example, library A can return a null in some obscure case without
documenting that behavior. Library B can interpret null as a meaningful
value and try to do something. You code sits in between, does some logic
and passes information from A to B.

Stuff like that is _very_ difficult to debug, and having non-nullable
types would make it much, much easier.

> What
> I would hope from a non-nullable type is to eliminate rare code paths
> where a null can occur, which might not show up in testing.
November 06, 2010
Re: Spec#, nullables and more
On 11/5/10 6:27 PM, Walter Bright wrote:
> Andrei Alexandrescu wrote:
>> The language may limit the static size of object. That's what Java
>> does - it limits the size of any class to 64KB, and then every VM
>> implementation guarantees that the first 64KB are made verboten one
>> way or another.
>
> I've meant to do that in D, but haven't gotten around to it.

Probably we should bugzillize it.

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


Andrei
November 06, 2010
Re: Spec#, nullables and more
On 11/5/10 6:54 PM, Michel Fortin wrote:
> On 2010-11-05 19:27:03 -0400, Walter Bright <newshound2@digitalmars.com>
> said:
>
>> Andrei Alexandrescu wrote:
>>> The language may limit the static size of object. That's what Java
>>> does - it limits the size of any class to 64KB, and then every VM
>>> implementation guarantees that the first 64KB are made verboten one
>>> way or another.
>>
>> I've meant to do that in D, but haven't gotten around to it.
>
> On 32-bit OS X, that limit is 4 KB.
>
> And what happens if I dereference a null pointer to a static array of
> 65k elements and I try to read the last one?
>
> Disallowing objects longer than 64 KB can help, but it's not a complete
> solution.

It is - it all depends on choosing the right limit for all OSs.

Andrei
November 06, 2010
Re: Spec#, nullables and more
On 2010-11-05 20:04:11 -0400, Walter Bright <newshound2@digitalmars.com> said:

> Michel Fortin wrote:
>> On 32-bit OS X, that limit is 4 KB.
> 
> That's good to know.

Well, you should already know. I posted this on the Phobos mailing list 
in August and you posted a reply. :-)


>> And what happens if I dereference a null pointer to a static array of 
>> 65k elements and I try to read the last one?
> 
> Array index out of bounds.

There's nothing out of the array's bounds in this case. Here's what I meant:

	byte[66000]* arrayPtr = null;
	byte b = (*arrayPtr)[66000-1];

I'm in the array's bounds here, the problem is that I'm dereferencing a 
null pointer but the program will actually only read 65999 bytes 
further, outside of the 64 KB "safe" zone.

Should we limit static arrays to 64 KB too?

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/
November 06, 2010
Re: Spec#, nullables and more
Michel Fortin wrote:
> On 2010-11-05 20:04:11 -0400, Walter Bright <newshound2@digitalmars.com> 
> said:
> 
>> Michel Fortin wrote:
>>> On 32-bit OS X, that limit is 4 KB.
>>
>> That's good to know.
> 
> Well, you should already know. I posted this on the Phobos mailing list 
> in August and you posted a reply. :-)

Yeah, well, my brain is full. In order to learn new facts, I must discard an 
equivalent number of existing ones. I've had to discard everything I ever 
learned about chemistry, for example.



>>> And what happens if I dereference a null pointer to a static array of 
>>> 65k elements and I try to read the last one?
>>
>> Array index out of bounds.
> 
> There's nothing out of the array's bounds in this case. Here's what I 
> meant:
> 
>     byte[66000]* arrayPtr = null;
>     byte b = (*arrayPtr)[66000-1];
> 
> I'm in the array's bounds here, the problem is that I'm dereferencing a 
> null pointer but the program will actually only read 65999 bytes 
> further, outside of the 64 KB "safe" zone.
> 
> Should we limit static arrays to 64 KB too?

That's why pointer arithmetic (which is what this is) is disallowed in safe mode.
November 06, 2010
Re: Spec#, nullables and more
Walter Bright:

> Yeah, well, my brain is full. In order to learn new facts, I must discard an 
> equivalent number of existing ones. I've had to discard everything I ever 
> learned about chemistry, for example.

As a human brain gets older, its ability to quickly retain new information decreases. When you are 18 years old you are able to learn lot of stuff the first time you hear it, while when you are 50 years old you need to listen to the same information some times to learn (unless you are very trained to learn a specific kind of information: a chess master is able to quickly memorize all the moves of a game even at old age).

But what you have said is partially wrong. The mammal brain doesn't have a fixed space for information, the more you learn the more space you have to learn, because while neurons are in finite number and their number decreases with age, new and synapses can be build every day, and higher level ways to store information in the semantic network may be invented by a mind.

Book titles about what I have said on request :-)

Keep learning,
bye,
bearophile
November 06, 2010
Re: Spec#, nullables and more
On 2010-11-05 23:27:28 -0400, Walter Bright <newshound2@digitalmars.com> said:

> Michel Fortin wrote:
>> There's nothing out of the array's bounds in this case. Here's what I meant:
>> 
>>     byte[66000]* arrayPtr = null;
>>     byte b = (*arrayPtr)[66000-1];
>> 
>> I'm in the array's bounds here, the problem is that I'm dereferencing a 
>> null pointer but the program will actually only read 65999 bytes 
>> further, outside of the 64 KB "safe" zone.
>> 
>> Should we limit static arrays to 64 KB too?
> 
> That's why pointer arithmetic (which is what this is) is disallowed in 
> safe mode.

Really? I'm doing two things in "(*arrayPtr)[66000-1]" in the above code:

1. Dereferencing a pointer to a the static array;
2. Accessing the last element within the bounds of the static array.

Which of these is disallowed in safe mode?

I think you should reread this example more attentively. It's no 
different than if you had put the static array as a member in a struct.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/
November 06, 2010
Re: Spec#, nullables and more
Michel Fortin wrote:
> On 2010-11-05 23:27:28 -0400, Walter Bright <newshound2@digitalmars.com> 
> said:
> 
>> Michel Fortin wrote:
>>> There's nothing out of the array's bounds in this case. Here's what I 
>>> meant:
>>>
>>>     byte[66000]* arrayPtr = null;
>>>     byte b = (*arrayPtr)[66000-1];
>>>
>>> I'm in the array's bounds here, the problem is that I'm dereferencing 
>>> a null pointer but the program will actually only read 65999 bytes 
>>> further, outside of the 64 KB "safe" zone.
>>>
>>> Should we limit static arrays to 64 KB too?
>>
>> That's why pointer arithmetic (which is what this is) is disallowed in 
>> safe mode.
> 
> Really? I'm doing two things in "(*arrayPtr)[66000-1]" in the above code:
> 
> 1. Dereferencing a pointer to a the static array;
> 2. Accessing the last element within the bounds of the static array.
> 
> Which of these is disallowed in safe mode?
> 
> I think you should reread this example more attentively. It's no 
> different than if you had put the static array as a member in a struct.
> 

Looks like you're right.
November 06, 2010
Re: Spec#, nullables and more
On 2010-11-06 05:46, bearophile wrote:
> Walter Bright:
>
>> Yeah, well, my brain is full. In order to learn new facts, I must discard an
>> equivalent number of existing ones. I've had to discard everything I ever
>> learned about chemistry, for example.
>
> As a human brain gets older, its ability to quickly retain new information decreases. When you are 18 years old you are able to learn lot of stuff the first time you hear it, while when you are 50 years old you need to listen to the same information some times to learn (unless you are very trained to learn a specific kind of information: a chess master is able to quickly memorize all the moves of a game even at old age).
>
> But what you have said is partially wrong. The mammal brain doesn't have a fixed space for information, the more you learn the more space you have to learn, because while neurons are in finite number and their number decreases with age, new and synapses can be build every day, and higher level ways to store information in the semantic network may be invented by a mind.
>
> Book titles about what I have said on request :-)
>
> Keep learning,
> bye,
> bearophile

Even though he may actually not forget a particular fact it will be 
harder and harder to find the fact because of other things "blocking the 
way". Eventaully it will seem you have forgot the fact.

-- 
/Jacob Carlborg
2 3 4 5 6 7 8
Top | Discussion index | About this forum | D home