View mode: basic / threaded / horizontal-split · Log in · Help
November 05, 2010
Re: Spec#, nullables and more
Ellery Newcomer wrote:
> On 11/05/2010 01:39 PM, Walter Bright wrote:
>>
>> It's infinitely worse. Null pointers do not result in memory corruption,
>> buffer overflows, and security breaches.
> Not true. Null pointer dereference exploits are difficult, but very real.


Is that like worrying that an airliner will crash into your house and explode?
November 05, 2010
Re: Spec#, nullables and more
Walter Bright Wrote:

> I think you misunderstand why checked exceptions are such a bad idea. It's not 
> just that they are inconvenient and annoying. They decrease security by *hiding* 
> bugs. That is the opposite of what you'd want in a high security language.

Not only is swallowing the exception a problem, but exceptions aren't added liberally in the code since every exception thrown/renamed effects all calling code. I'm still not in the habit of asserting assumptions.
November 05, 2010
Re: Spec#, nullables and more
Fri, 05 Nov 2010 09:53:50 -0400, Gary Whatmore wrote:

> bearophile Wrote:
> 
>> Ellery Newcomer:
>> 
>> > hey, cool
>> > 
>> > stumbled on sing# a while ago and thought it was intriguing, or at
>> > least the fact that ms was using it to write an OS kernel
>> 
>> It contains a ton of new computer science ideas :-) So it's interesting
>> regardless its applications. (If you don't keep yourself updated with
>> new computer science ideas, you can't keep being a productive
>> programmer for many years).
> 
> Are you saying that Walter Bright or anyone else here isn't as
> productive as you are because we haven't read about the latest language
> research done between 1980 and 2010? Keeping yourself updated with new
> ideas also means pragmatic real world books, not just ivory tower
> research papers that usually aren't freely accessible without an
> expensive subscription:
> 
> http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/
dp/0132350882/
> http://www.amazon.com/Domain-Specific-Languages-Addison-Wesley-
Signature-Martin/dp/0321712943/
> http://www.amazon.com/D-Programming-Language-Andrei-Alexandrescu/
dp/0321635361/
> http://www.amazon.com/Lean-Architecture-Agile-Software-Development/
dp/0470684208/
> http://www.amazon.com/Mythical-Man-Month-Software-Engineering-
Anniversary/dp/0201835959/
> http://www.amazon.com/Pragmatic-Programmer-Journeyman-Master/
dp/020161622X/
> http://www.amazon.com/Programming-Massively-Parallel-Processors-Hands/
dp/0123814723/
> http://www.amazon.com/Refactoring-Improving-Design-Existing-Code/
dp/0201485672/
> http://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530/
> http://www.amazon.com/Version-Control-Git-Collaborative-Development/
dp/0596520123/
> http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/
dp/0131177052/
> 
> Do I need to say more?

Those all books deal with tools and non-academic best practices. Probably 
useful information, but it's not necessarily built on previous (written) 
knowledge about the domain. The more academic papers discuss why some 
algoritm works, how to measure it analytically, how language constructs 
are built from smaller pieces etc. You should at least read few of those 
to get a better view of the literature.

Programming language research has indeed found new techniques and results 
since the idea of OOP came some 30 to 40 years ago. Nothing suggests that 
OOP is the be-all and end-all of programming language design. See the 
links at http://harmful.cat-v.org/software/OO_programming/

Even D is slowly adopting real lambdas, algebraic data types, tuples, and 
all kinds of functional features.
November 05, 2010
Re: Spec#, nullables and more
On 11/05/2010 02:24 PM, Walter Bright wrote:
> Ellery Newcomer wrote:
>> On 11/05/2010 01:39 PM, Walter Bright wrote:
>>>
>>> It's infinitely worse. Null pointers do not result in memory corruption,
>>> buffer overflows, and security breaches.
>> Not true. Null pointer dereference exploits are difficult, but very real.
>
>
> Is that like worrying that an airliner will crash into your house and
> explode?

Don't know. Has anyone ever crashed into my house with an airliner and 
lived to tell about it?
November 05, 2010
Re: Spec#, nullables and more
Daniel Gibson, el  5 de noviembre a las 19:52 me escribiste:
> Walter Bright schrieb:
> >bearophile wrote:
> >>Walter Bright:
> >>
> >>>The $10 billion mistake was C's conversion of arrays to pointers when
> >>>passing to a function.
> >>>
> >>>http://www.drdobbs.com/blog/archives/2009/12/cs_biggest_mist.html
> >>>
> >>>Sadly, there's an ongoing failure to recognize this, as it is never
> >>>addressed in any of the revisions to the C or C++ standards,
> >>
> >>I agree, that's a very bad problem, probably worse than
> >>null-related bugs.
> >
> >It's infinitely worse. Null pointers do not result in memory
> >corruption, buffer overflows, and security breaches.
> >
> 
> Not entirely true: Null Pointer dereferences *have* been used for
> security breaches, see for example: http://lwn.net/Articles/342330/
> The problem is that one can mmap() to 0/NULL so it can be dereferenced without causing a crash.
> 
> Of course this is also a problem of the OS, it shouldn't allow
> mmap()ing to NULL in the first place (it's now forbidden by default
> on Linux and FreeBSD afaik) - but some software (dosemu, wine)
> doesn't work without it.

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.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
<mazzi> gmail is down?
<Luca> waiting for mail.google.com....
<mazzi> ya vendí todas mis acciones de google en los mercados asiaticos
<Luca> se viene la ecatombe
<mazzi> mal
<mazzi> es como que te corten el porno en una tarde al pedo en tu casa
November 05, 2010
Re: Spec#, nullables and more
On 11/5/10 4:12 PM, Leandro Lucarella wrote:
> Daniel Gibson, el  5 de noviembre a las 19:52 me escribiste:
>> Walter Bright schrieb:
>>> bearophile wrote:
>>>> Walter Bright:
>>>>
>>>>> The $10 billion mistake was C's conversion of arrays to pointers when
>>>>> passing to a function.
>>>>>
>>>>> http://www.drdobbs.com/blog/archives/2009/12/cs_biggest_mist.html
>>>>>
>>>>> Sadly, there's an ongoing failure to recognize this, as it is never
>>>>> addressed in any of the revisions to the C or C++ standards,
>>>>
>>>> I agree, that's a very bad problem, probably worse than
>>>> null-related bugs.
>>>
>>> It's infinitely worse. Null pointers do not result in memory
>>> corruption, buffer overflows, and security breaches.
>>>
>>
>> Not entirely true: Null Pointer dereferences *have* been used for
>> security breaches, see for example: http://lwn.net/Articles/342330/
>> The problem is that one can mmap() to 0/NULL so it can be dereferenced without causing a crash.
>>
>> Of course this is also a problem of the OS, it shouldn't allow
>> mmap()ing to NULL in the first place (it's now forbidden by default
>> on Linux and FreeBSD afaik) - but some software (dosemu, wine)
>> doesn't work without it.
>
> 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.

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.


Andrei
November 05, 2010
Re: Spec#, nullables and more
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?
November 05, 2010
Re: Spec#, nullables and more
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.
November 05, 2010
Re: Spec#, nullables and more
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.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/
November 06, 2010
Re: Spec#, nullables and more
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.

That's good to know.


> 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.


> Disallowing objects longer than 64 KB can help, but it's not a complete 
> solution.

It's pretty darn close.
1 2 3 4 5 6 7 8
Top | Discussion index | About this forum | D home