[Freedos-kernel] A question about the behavior of the NUL device in FreeDOSS 1.1

[Juan M. G. <jua...@gm...>]

Please note that I have not followed any of the FreeDOS mailing lists on a
regular base.  This means that I may report something that is already well
known.  Also I do not know if this is the right mailing list to post this
bug report.


Please inspect the small code snippet below:

#include <unistd.h>
#include <fcntl.h>
#include <stdio.h>

#define SIZE  256


int main(int argc, char *argv[])
{
   char buffer[SIZE];
//  int handle = open(argc > 1 ? argv[1] : "/dev/null", O_RDONLY);
   int handle = open(argc > 1 ? argv[1] : "NUL", O_RDONLY);
   int len = read(handle, buffer, SIZE);
   printf("len=%d\n", len);
   if (len > 0)
   {
     int i, k;
     for (i = 0; i < len; i += 16)
     {
       for (k = 0; k < 16 && i + k < len; k++)
         printf(" %02X", (unsigned char)buffer[i + k]);
       printf("\n");
     }
   }
   return 0;
}


This code has been compiled on MSDOS and Windows using DJGPP.  It has also been
compiled on linux as reference.  All programs behave as expected on all tested
operating systems, this means that /dev/null (aka NUL) provides nothing and the
program prints:

len=0

as it must be.  If the same program runs on FreeDOS 1.1 it produces the
following output:

len=256
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00


No offending intention here, but have the developers confound /dev/null
with /dev/zero?  IMHO the NUL device seems to be broken.


This issue is critical when bash configure scripts of GNU software packages
contain lines like this:
   awk 'BEGIN {getline < "/dev/null"}'
making the configuration step abort and thus the complete build of the software
impossible if FreeDOS is used instead of MSDOS or Windows.

Please note that I have also tried NUL instead of /dev/null in the code and the
program fails in the same way.  This means this is certainly not a DJGPP bug.
The program fails in the same way if compiled with OpenWATCOM 1.9.
If more information is required, please contact me.

Regards,
Juan M. Guerrero