From mboxrd@z Thu Jan 1 00:00:00 1970 From: smiley@zenzebra.mv.com To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> References: <86ipx4s36p.fsf@cmarib.ramside> Date: Tue, 1 Feb 2011 17:51:23 +0000 In-Reply-To: (ron minnich's message of "Mon, 31 Jan 2011 22:45:49 -0800") Message-ID: <86ei7ry76s.fsf@cmarib.ramside> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [9fans] RESOLVED: recoving important header file rudely Topicbox-Message-UUID: a6de67d4-ead6-11e9-9d60-3106f5b1d025 ron minnich writes: >> term% cp abc* abc* x >> # watch the cp executable suicide >> # now, make SURE there's nothing in this rio window that you want to keep... >> term% rm abc* >> # watch the rio window go bye bye! >> > > it's not cp and it's not rio. I think you need to diagnose this a bit > better. If you look a bit more at it I think you'll see what's going > on. I know the cp suicide is a problem in cp, because I designed the test case to exercise a buffer overflow I found at /sys/src/cmd/cp.c:77,93 void copy(char *from, char *to, int todir) { Dir *dirb, dirt; char name[256]; int fdf, fdt, mode; if(todir){ char *s, *elem; elem=s=from; while(*s++) if(s[-1]=='/') elem=s; sprint(name, "%s/%s", to, elem); to=name; } The bug in rc's globbing was just a fun "bonus" I discovered while trying to clean up after the cp test. :) > but I have to wonder if you've been inside glibc lately. I don't think Agreed. glibc has become quite ugly. > There are other, very good paradigms that the code does use, such as > lock-free threads. Threads are one great paradigm that Plan 9 adopted. Native UTF-8 is another. However, the Plan 9 code (at last that under /sys/src/cmd) doesn't seem to make use of iterators, string objects (or even object-orientation), modern string parsing routines, etc. All of these programming techniques can free the programmer from having to think about byte-level boundary conditions and focus on the higher-level operation of the code. Having to tend to such details over and over again leads to lots of missed boundary conditions (like in cp.c and plan9.c), application instability, and security vulnerabilities (remember the factotum exploit?) It's probably worth noting that higher-level code abstractions are probably more useful in userspace code than in the kernel. This is partly for reasons of performance, and partly because the kernel is so much closer to the hardware. The Linux kernel, for example, is still largely written in old UNIX-style C. It wasn't even until series 2.5 or so that the Linux kernel became palpably object-oriented. > The common problem is that people come to Plan 9 and view it through > the prism of their experiences with other systems such as Linux. Yes, I am familiar with the notion that the Plan 9 way is very different from other ways, such as the Linux way. One of the things that I enjoy about Plan 9 is that it makes me feel naive again. :) -- +---------------------------------------------------------------+ |E-Mail: smiley@zenzebra.mv.com PGP key ID: BC549F8B| |Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B| +---------------------------------------------------------------+