Re: [9fans] Is Plan 9 C "Less Dangerous?"
On 9/3/18, Ethan Gardener wrote: > On Mon, Sep 3, 2018, at 1:40 PM, Chris McGee wrote: >> While the idea that many eyes makes bugs shallower seems to have failed >> in the world of complex behemoth software it may work here. > > I think it worked for a while, but eventually complexity grew beyond even > the many eyes approach. > Could even be that the many-eyes approach encouraged the complexity; in fact, that could easily be the unintended consequence. Lucio.
Re: [9fans] Is Plan 9 C "Less Dangerous?"
On Tue, Sep 4, 2018, at 11:51 AM, Lucio De Re wrote: > On 9/3/18, Ethan Gardener wrote: > > On Mon, Sep 3, 2018, at 1:40 PM, Chris McGee wrote: > >> While the idea that many eyes makes bugs shallower seems to have failed > >> in the world of complex behemoth software it may work here. > > > > I think it worked for a while, but eventually complexity grew beyond even > > the many eyes approach. > > > Could even be that the many-eyes approach encouraged the complexity; > in fact, that could easily be the unintended consequence. I suppose it made complexity seem less bad, for a while, but I was thinking economic factors likely drove it to get more complex. Also, I get the impression that some people just love complexity, but these days I'm not so sure. Complexity does have some real benefits.
Re: [9fans] Is Plan 9 C "Less Dangerous?"
> > Could even be that the many-eyes approach encouraged the complexity; > > in fact, that could easily be the unintended consequence. > > I suppose it made complexity seem less bad, for a while, but I was > thinking economic factors likely drove it to get more complex. Also, I get > the impression that some people just love complexity, but these days I'm > not so sure. Complexity does have some real benefits. > I hadn't considered this. I just assumed that complexity = job security + sell + lock-in. It's easy to love something that is raking in the cash.
Re: [9fans] Is Plan 9 C "Less Dangerous?"
Plan 9 C implements C by attempting to follow the programmer's instructions, which is surprisingly useful in systems programming. The big fat compilers work hard to find grounds to interpret those instructions as "undefined behaviour". On Sun, 2 Sep 2018 at 17:32, Chris McGee wrote: > Hi All, > > I'm reading this article about how they are going through the giant > heaping pile of Linux kernel code and trying to come up with safer > practices to avoid the "dangers" of C. The prevailing wisdom appears to be > that things should eventually be rewritten in Rust some day. > > https://lwn.net/SubscriberLink/763641/c9a04da2a33af0a3/ > > I'm curious how the Plan 9 C compiler fits into this story. I know that it > was designed to avoid many of the pitfalls of standard C. Does it try to > address some of these dangers or is it focused on making code more readable > so that problems are more apparent? > > How does everyone feel about the Plan 9/9front kernel? Have they gone > through hardening/testing exercises over the years? I'm curious what tools > are available to help discover bugs. > > Cheers, > Chris >
Re: [9fans] Is Plan 9 C "Less Dangerous?"
Ha HA ! Good one ! I believe that the core of the problem with the C language is that is based upon abstracting the PDP-11 instruction set. CPUs, such as Intel/AMD x64 are vastly more complex so "optimising" C compilers are trying to make something simple take advantage of something far more complex. Perhaps we should call them "complexifying" compilers. Generally, model-to-model transformations (which is effectively what compilers do under the covers) are easier to define when we transform from a higher level of abstraction to a lower level of abstraction. As folks in the MBSE field explain it, trying to put a pig together from sausages. On Wed, 5 Sep 2018 at 09:20, Charles Forsyth wrote: > Plan 9 C implements C by attempting to follow the programmer's > instructions, which is surprisingly useful in systems programming. > The big fat compilers work hard to find grounds to interpret those > instructions as "undefined behaviour". > > > On Sun, 2 Sep 2018 at 17:32, Chris McGee wrote: > >> Hi All, >> >> I'm reading this article about how they are going through the giant >> heaping pile of Linux kernel code and trying to come up with safer >> practices to avoid the "dangers" of C. The prevailing wisdom appears to be >> that things should eventually be rewritten in Rust some day. >> >> https://lwn.net/SubscriberLink/763641/c9a04da2a33af0a3/ >> >> I'm curious how the Plan 9 C compiler fits into this story. I know that >> it was designed to avoid many of the pitfalls of standard C. Does it try to >> address some of these dangers or is it focused on making code more readable >> so that problems are more apparent? >> >> How does everyone feel about the Plan 9/9front kernel? Have they gone >> through hardening/testing exercises over the years? I'm curious what tools >> are available to help discover bugs. >> >> Cheers, >> Chris >> >
Re: [9fans] Is Plan 9 C "Less Dangerous?"
> I believe that the core of the problem with the C language is that is > based upon abstracting the PDP-11 instruction set. CPUs, such as Intel/AMD > x64 are vastly more complex so "optimising" C compilers are trying to make > something simple take advantage of something far more complex. Perhaps we > should call them "complexifying" compilers. > > Generally, model-to-model transformations (which is effectively what > compilers do under the covers) are easier to define when we transform from > a higher level of abstraction to a lower level of abstraction. As folks in > the MBSE field explain it, trying to put a pig together from sausages. > I wonder if the hardware world suffers from some of the same complexity problems the software world does. Is it possible to build much simpler hardware as well or are there real physical properties that force them to be as complex as they are now?
Re: [9fans] Is Plan 9 C "Less Dangerous?"
On Wed, 5 Sep 2018 09:30:22 +1000, Tyga wrote: > Ha HA ! Good one ! > CPUs, such as Intel/AMD x64 > are vastly more complex so "optimising" C compilers are trying to make > something simple take advantage of something far more complex. Ironically, because of the complexity in the CPUs, many of the optimizations make less of a difference now -- they're essentially optimizing just in time compilers under the hood, so even terrible code will run acceptably quickly. -- Ori Bernstein
