Re: some PRs

From: Sergey Babkin (babkin_at_bellatlantic.net)
Date: 07/27/04

  • Next message: Pawel Jakub Dawidek: "Re: some PRs" 
    Date: Tue, 27 Jul 2004 12:36:48 -0400
To: Giorgos Keramidas <keramida@ceid.upatras.gr>

    Giorgos Keramidas wrote:
    >
    > On 2004-07-26 19:49, Sergey Babkin <babkin@bellatlantic.net> wrote:
    > > Max Laier wrote:
    > > > The question to me is, do we really want to support (read fertilize)
    > > > such a stupid thing? Given the chance that once we do support it
    > > > people will use it. In my opinion it is bad to integrate something
    > > > into base that we agree is nothing one should ever have created (at
    > > > least that's my reading of the thread so far). I see no user-pessure
    > > > for this.
    > >
    > > I'm about a week behind :-) but here are my 2 cents: it's a VERY
    > > useful device for testing. Not checking the error code of write(),
    > > printf() and such is a typical bug, so making it easy to detect by
    > > switching the output to /dev/full (or creating a symlink to it) is a
    > > very good idea. Like this:
    > >
    > > yourprogram >/dev/full \
    > > && echo "The program does not check for success of write()"
    >
    > If a program doesn't check the return code of write() but merrily goes
    > on doing other stuff or even terminates with a zero return value, how
    > will the redirection affect its operation? I think it won't, as shown
    > in the test below (run on a Linux machine):

    If you run a test in which you know the program must fail (such
    as writing to /dev/full) yet it does not, this means that there
    is abug in the program.
     
    > : $ ls -ld /dev/full
    > : crw-rw-rw- 1 root root 1, 7 Jun 14 00:24 /dev/full
    > : $ cat -n lala.c
    > : 1 #include <sys/types.h>
    > : 2 #include <string.h>
    > : 3 #include <unistd.h>
    > : 4
    > : 5 int
    > : 6 main(void)
    > : 7 {
    > : 8 char buf[] = "hello world\n";
    > : 9 size_t len;
    > : 10
    > : 11 len = strlen(buf);
    > : 12 write(1, buf, len);
    > : 13 return 0;
    > : 14 }
    > : $ cc -O -W -Wall -o lala lala.c
    > : $ ./lala
    > : hello world
    > : $ ./lala >/dev/full
    > : $ echo $?
    > : 0
    > : $
    >
    > The fact that /dev/full was used as the output device didn't reveal the
    > potential write() problem.

    That's _exactly my point: if the program writes to /dev/full
    and yet does produce an error exit code or an error message,
    there is a bug in the program.
     
    > I must have misunderstood something. How do you mean that we could use
    > /dev/full for testing?

    Well, as described above: for each file that your program can produce,
    try to substitute it with /dev/full and watch the prgoram fail.
    If it does not fail, there is a bug. That's much easier than producing
    an actual full filesystem.

    -SB
    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

  • Next message: Pawel Jakub Dawidek: "Re: some PRs"

    Relevant Pages