Re: [9fans] RESOLVED: recoving important header file rudely

[smiley@zenzebra.mv.com]

ron minnich <rminnich@gmail.com> 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|
+---------------------------------------------------------------+