![](/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 <dne### [at] san rr com> wrote:
> > For a project like the Linux kernel that is aimed at high portability,
>
> Well, no. The Linux kernel wasn't started aimed at high portability. Just
> the opposite, really.
Yeah, but what is the *current* aim?
> > Another reason is speed, of course, but just like with Assembler it could be
> > argued that only the most heavily-used portions of a project should resort to C
> > for speed these days.
>
> Mmmm.... Debatable. :-) It really depends on the rest of the system. If
> you're writing in some language fundamentally different from C, you might
> spend more time translating into C data structures than you do to run it.
> Nobody says "Wow, this SQL query is really slow. Let's rewrite it in C."
I said, it *could* be argued. And BTW, *some* SQL queries are indeed easier to
do by just pumping the data into a C program and doing the filtering & sortng
manually (though generally you'd first have a look to see if you can somehow
improve performance by tweaking the DB, rephrasing the query, or the like).
And in general, serious languages tend to have *some* generic interface to
libraries written in C (though then again, some of these interfaces seem to be
pathological, as with Perl for instance; seen a colleague once struggling to
pass a NULL pointer or some such into a C API function).
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) |
clipka wrote:
> Yeah, but what is the *current* aim?
From *my* experience, the current aim is to dick around with it for fun so
it takes several weeks of intense concentration and trial-and-error to get
each new point release to even compile.
> I said, it *could* be argued. And BTW, *some* SQL queries are indeed easier to
> do by just pumping the data into a C program and doing the filtering & sortng
> manually (though generally you'd first have a look to see if you can somehow
> improve performance by tweaking the DB, rephrasing the query, or the like).
Exactly. My point was that nobody rewrites a chunk of SQL in C. They pull
the data and manipulate it in C, which is rather different from cracking
open the RDBMS and modifying it to add their query as a SQL primitive. :-)
> And in general, serious languages tend to have *some* generic interface to
> libraries written in C
Sure, but that's because C is close to assembler. Anything with a reasonable
calling convention can do that, assuming the CPU is designed to run C. Most
of them also have some generic interface to Windows COM as well. I'm not
sure what the point is. :-)
LISP machines, Smalltalk machines, and FORTH machines all lack generic
interfaces to libraries written in C. :-)
> (though then again, some of these interfaces seem to be
> pathological, as with Perl for instance; seen a colleague once struggling to
> pass a NULL pointer or some such into a C API function).
Precisely my point. The farther from C your language gets, the less likely
you can easily invoke C.
--
Darren New, San Diego CA, USA (PST)
"We'd like you to back-port all the changes in 2.0
back to version 1.0."
"We've done that already. We call it 2.0."
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) |
Here's a whole description of the whole chain of events that led up to it
breaking. I don't know if it got posted before, but it's pretty interesting.
http://lwn.net/SubscriberLink/342330/f66e8ace8a572bcb/
--
Darren New, San Diego CA, USA (PST)
"We'd like you to back-port all the changes in 2.0
back to version 1.0."
"We've done that already. We call it 2.0."
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:
> Here's a whole description of the whole chain of events that led up to it
> breaking. I don't know if it got posted before, but it's pretty interesting.
> http://lwn.net/SubscriberLink/342330/f66e8ace8a572bcb/
"But Herbert's patch added a line which dereferences the pointer prior
to the check. That, of course, is a bug."
That's what I thought. You can't blame a compiler optimization for
"screwing up" buggy code, even though without the optimization the bug
would perhaps not have been symptomatic by pure chance.
--
- 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) |