Spec#, nullables and more

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Fri Nov 5 15:28:23 PDT 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


More information about the Digitalmars-d mailing list