Discussion:
[Freedos-kernel] A question about the behavior of the NUL device in FreeDOSS 1.1
Juan Manuel Guerrero
2013-12-18 12:29:24 UTC
Permalink
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
p***@gmail.com
2013-12-25 23:57:10 UTC
Permalink
Thank you for the report and test program. The issue is a conversion in
chario.c from int to char causing the sentinel 256 to be truncated to 0. I
need to apply my fix to a clean tree then I will forward it to the list.

Thank you,
Jeremy
dos386
2014-01-01 17:47:07 UTC
Permalink
Thanks for reporting and fixing FreeDOS kernel BUG's :-)

Loading...