Re: some PRs

From: Giorgos Keramidas (keramida_at_ceid.upatras.gr)
Date: 07/27/04

  • Next message: Giorgos Keramidas: "Re: some PRs"
    Date: Tue, 27 Jul 2004 06:29:17 +0300
    To: Sergey Babkin <babkin@bellatlantic.net>
    
    

    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):

    : $ 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.

    I must have misunderstood something. How do you mean that we could use
    /dev/full for testing?
    _______________________________________________
    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: Giorgos Keramidas: "Re: some PRs"

    Relevant Pages

    • kernel compilation gives error
      ... *** Error code 1 ... # Floating point support - do not disable. ... # PCI Ethernet NICs that use the common MII bus ... # exists only as a PCMCIA device, so there is no ISA ...
      (freebsd-questions)
    • kernel compile PAE option
      ... When I try to compile kernel options PAE i get following error: ... *** Error code 1 ... options SOFTUPDATES # Enable FFS soft updates support ... # SCSI Controllers ...
      (freebsd-current)
    • custom kernel compile error, please help
      ... aal_sscop.c:4300: error: incompatible type for argument 1 of `ng_untimeout' ... *** Error code 1 ... # Floating point support - do not disable. ... # PCI Ethernet NICs that use the common MII bus controller code. ...
      (freebsd-current)
    • Error in kernel source, possibly GCC related
      ... I am at this moment compiling the kernel, and I get this error when make ... *** Error code 1 ... # Floating point support - do not disable. ... # PCI Ethernet NICs that use the common MII bus controller code. ...
      (freebsd-stable)
    • KERNEL PROB
      ... *** Error code 1 ... # RAID controllers interfaced to the SCSI subsystem ... # Floating point support - do not disable. ... # PCI Ethernet NICs that use the common MII bus controller code. ...
      (freebsd-questions)