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


>> and is missed by the supposedly "safe C" alternatives.
> 
> This is probably wrong. I don't know many C alternatives, but the well known
> Cyclone language uses fat pointers (and other things) to solve that C
> problem.


The Cyclone user manual says you have to rewrite a parameter as:

    void foo(int *@numelts(4) arr);

to avoid the bugs with:

    void foo(int arr[]);

I think that latter broken syntax is still supported by Cyclone, but with the inadequate manual http://cyclone.thelanguage.org/wiki/User%20Manual it's hard to tell.

Oh, and you have to redeclare the C:

    int sum(int num, int *p);

as:

    int sum(tag_t<`n> num,
        int *@notnull @numelts(valueof(`n)) p);

No wonder Cyclone failed.
November 05, 2010
bearophile wrote:
> Walter Bright:
> 
>> Checked exceptions are one of those ideas that look great on paper but are
>> an utter failure in practice. As Bruce Eckel pointed out, they are *worse*
>> than useless and *cause* bugs to be inserted into the code.
> 
> (Just to avoid possible misunderstandings: I have never suggested to add
> checked exceptions to D).

I just have a hard time seeing that Spec# is an advanced language incorporating the latest in comp sci thought when it adds checked exceptions.


> I agree that checked exceptions are a pain in a general purpose language. But
> Spec# isn't a general purpose language, it's designed to be a high integrity
> language, where the user is supposed to endure some pain in the hope to
> produce statically verified (and less buggy) programs. So while checked
> exceptions are probably a bad idea for a handy general purpose language, the
> authors of Spec# have thought that for the special purposes of Spec# those
> exceptions are justified. I don't know if they are right (maybe they are
> wrong, surely not everything in Spec# design is perfect, despite it generally
> looks like a really well though out language). But you need to keep in
> account the quite special purpose of Spec# before judging if adding checked
> exceptions to Spec# is a bad idea.

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.

http://www.mindview.net/Etc/Discussions/CheckedExceptions


Spec# and Cyclone both fall into the trap of making the right thing to do hard, and the wrong thing easy.
November 05, 2010
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.

Cheers,
- Daniel
November 05, 2010
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.
November 05, 2010
Gary Whatmore wrote:
> Pelle M�nsson Wrote:
> 
>> On 11/05/2010 12:43 PM, Gary Whatmore wrote:
>>> bearophile Wrote:
>>>> - A way to list what attributes are modified in a method (similar to my @outer).
>>> The compiler should do this itself.
>> Doesn't make sense.
>>
>>>> My reference issue: http://d.puremagic.com/issues/show_bug.cgi?id=4571
>>> Walter, please close this as wontfix. We don't need those. These extra runtime checks will slow down my code. I know myself when my pointer is null.
>>>
>>>   - G.W.
>> How, exactly, do you know when your references are null? Without runtime checks, of course.
> 
> Good code design makes the null pointer exceptions go away. I carefully ponder what code goes where. Simple as that. That language just introduces a boatload of unnecessary cruft in forms of runtime null checks. I don't need to know the exact temporal location of nulls, it's enough if the code takes care of handling it at run time.

	Who said anything about runtime checks? Non-nullable types are
enforced at compile-time anyway...

		Jerome
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr



November 05, 2010
bearophile wrote:
> If you take a look at the Go site you see a way to try code:
> http://golang.org/

Yes, I know about that site and the accolades heaped on Go for having it. Meanwhile, codepad has had it for years, and comeaucomputing has had it for at least 20 years now (for Comeau C++), and nobody cared.

I agree they do no harm, but once you're past the gee-whiz factor, they aren't of much use.
November 05, 2010
Fri, 05 Nov 2010 13:36:18 -0400, bearophile wrote:
> Walter:
> 
>> http://codepad.org/
>> 
>> It's been around a while, and nobody cares. Such a capability is marketing puffery, and not useful.

> If you go take a visit to the IRC #D channel you see an tool based on codepad that allows to try snippets of code from the IRC channel itself. A tool often used by feep and others.
> 
> So you are wrong, ideone/codepad are used by people, are good marketing, allow people to try D before installing the compiler and they don't harm D in any way.

It feels like these introvert academic profs and compiler developers with huge beards are actually getting more pragmatic than our BDFL. They regularly visit their IRC channels and are fluently using these online tools. They even adopted open source version control tools and public repositories before Walter did. Just take a look at Scala's trac.. This shouting from the "pragmatic" ivory tower is getting out of touch with reality.
November 05, 2010
Fri, 05 Nov 2010 13:40:59 -0400, 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. But Java, C#, and D have solved this problem already, so we can now go on and try to solve other problems. This thread was about a different problem (null-related bugs), currently present in Java, C#, and D too.

One first needs to study these more modern languages before he/she can form any kind of relevant opinions.

>> and is missed by the supposedly "safe C" alternatives.
> 
> This is probably wrong. I don't know many C alternatives

The primary competition of D is all "safe/better" C clones, and naturally C and C++. D is trying to beat C and C++. To me it seems like the authors fail to see how and why more modern languages succeed.
November 05, 2010
Walter Bright:

> I agree they do no harm, but once you're past the gee-whiz factor, they aren't of much use.

Yet, I will keep using ideone almost daily :-)

Bye,
bearophile
November 05, 2010
Daniel Gibson wrote:
> Walter Bright schrieb:
>> 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.

I'm surprised. 20 years ago, OS design articles I've seen all said that the first thing to do was render the bottom 64Kb of address space inaccessible in order to catch null pointer dereferences. People were pretty fed up with Intel's decision to put the interrupt table in the first page of addresses, so any null pointers promptly trashed the operating system.

(Intel should have put the BIOS boot rom at location 0.)