November 05, 2010
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
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
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
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
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
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
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
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
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
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.