![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New wrote:
> """
> "I cannot recommend people switch due to this one flaw," said John
> Curran, head of Microsoft UK's Windows group.
> """
> No, of course you can't.
Shocker.
> Looks like another image processing buffer overflow.
At times like this, I find myself wondering. About two things.
1. If the entire system was written in some "safe" language, would we
still have 45 buffer overflow flaws per week reported?
2. How much slower would the whole contraption be? (I'm guessing it
would make Vista look *fast*...)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Orchid XP v8 wrote:
> 1. If the entire system was written in some "safe" language, would we
> still have 45 buffer overflow flaws per week reported?
No. Pretty much by definition. You might still have holes, but they'd be
different holes.
> 2. How much slower would the whole contraption be? (I'm guessing it
> would make Vista look *fast*...)
It would be about 30% faster.
--
Darren New, San Diego CA, USA (PST)
The NFL should go international. I'd pay to
see the Detroit Lions vs the Roman Catholics.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> 1. If the entire system was written in some "safe" language, would we
>> still have 45 buffer overflow flaws per week reported?
>
> No. Pretty much by definition. You might still have holes, but they'd
> be different holes.
>
>> 2. How much slower would the whole contraption be?
>
> It would be about 30% faster.
Right. So you're telling me that if you wrote an OS and all the
associated large-scale applications in a "safe" language, it would be
more secure, and run faster (and obviously take drastically less time to
develop).
And people still write all OS and application software in C because...??
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 16-Dec-08 21:48, Orchid XP v8 wrote:
>>> 1. If the entire system was written in some "safe" language, would we
>>> still have 45 buffer overflow flaws per week reported?
>>
>> No. Pretty much by definition. You might still have holes, but they'd
>> be different holes.
>>
>>> 2. How much slower would the whole contraption be?
>>
>> It would be about 30% faster.
>
> Right. So you're telling me that if you wrote an OS and all the
> associated large-scale applications in a "safe" language, it would be
> more secure, and run faster (and obviously take drastically less time to
> develop).
>
> And people still write all OS and application software in C because...??
>
because the manager is from a completely different field and tried to
catch up with the state of the art by reading K&R.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> wrote:
> > 2. How much slower would the whole contraption be? (I'm guessing it
> > would make Vista look *fast*...)
> It would be about 30% faster.
If it would indeed by 30% faster, that would only be a sign that the
current codebase sucks. (Of course being MS, that would hardly surprise
anyone.)
If the codebase sucks, it means the programmers are incompetent. Would
a change in programming language make them less incompetent?
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
andrel <a_l### [at] hotmail com> wrote:
> > And people still write all OS and application software in C because...??
> >
> because the manager is from a completely different field and tried to
> catch up with the state of the art by reading K&R.
Of because the vast majority of libraries out there you need to write
something like an OS are written in C.
Also C is conveniently low-level so that you can quite accurately access
asm and hardware directly.
Do languages like Haskell even support inline asm, linking to asm routines,
or accessing hardware directly (other than with wrappers around existing
C libraries)?
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 16-Dec-08 22:46, Warp wrote:
> Darren New <dne### [at] san rr com> wrote:
>>> 2. How much slower would the whole contraption be? (I'm guessing it
>>> would make Vista look *fast*...)
>
>> It would be about 30% faster.
>
> If it would indeed by 30% faster, that would only be a sign that the
> current codebase sucks. (Of course being MS, that would hardly surprise
> anyone.)
>
> If the codebase sucks, it means the programmers are incompetent. Would
> a change in programming language make them less incompetent?
>
A couple of possible answers:
- you take it a bit too serious
- not all programmers are equally competent at every level. A good
programming system and language can result in a better match for every
team member.
- C does not provide build in error checking, which means that often
data is checked both in the calling and the called function even if you
can simply prove that it will comply to the precondition. That might
give 30% slowing down in some cases. Of course there are also cases wher
both end fail to check, assuming that it is a task of the other. That
result in unreliable code.
- A language comes with a paradigm which enables solving problems in
certain ways. I am doing things in Matlab that I would not do in C
because although the languages are similar, some things are a few
keystrokes in Matlab and 20+ lines of code in C. Just as that some
things are more easy expressed in sql or prolog or with lex/yacc than in
C and run faster (even if you could do it in C and even if C was used as
an intermediate step).
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
andrel <a_l### [at] hotmail com> wrote:
> Just as that some
> things are more easy expressed in sql or prolog or with lex/yacc than in
> C and run faster
That last point I don't buy.
You can do *anything* with C. You can exactly replicate the machine code
run by SQL or prolog in C. It may be more laborious to do in C than in SQL
or prolog, but it will certainly not run slower.
If you *don't know how* to make it equally fast in C, that's a completely
different, unrelated issue.
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 16-Dec-08 23:40, Warp wrote:
> andrel <a_l### [at] hotmail com> wrote:
>> Just as that some
>> things are more easy expressed in sql or prolog or with lex/yacc than in
>> C and run faster
>
> That last point I don't buy.
>
> You can do *anything* with C.
to quote my next line after that '(even if you could do it in C and even
if C was used as an intermediate step)'. So, yes I am aware that you
could, but the point is that you wouldn't.
You can implement on the fly garbage collection in C but if your library
does not support that you simply won't do that when writing e.g. a
simple TCP stack. In that case you simply allocate a buffer that is
large enough. And we all know what happens next. If you have a
language/system that does support that you go for a different solution.
I am not saying that is as it should be, simply that is like it is.
Another more safe example (as less religious aspects are involved) is
something like battle chess. There is of course a PC version of it, but
it would not have come to life if it was not for the blitter in the
Amiga. There are numerous examples of this kind where the solution space
for a project is shaped by the available hardware/language/libraries.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Orchid XP v8 wrote:
> Right. So you're telling me that if you wrote an OS and all the
> associated large-scale applications in a "safe" language, it would be
> more secure, and run faster (and obviously take drastically less time to
> develop).
Yes. Primarily because then you could turn off the memory management, the
overhead of protection rings, and so on.
> And people still write all OS and application software in C because...??
Legacy.
--
Darren New, San Diego CA, USA (PST)
The NFL should go international. I'd pay to
see the Detroit Lions vs the Roman Catholics.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |