fopen() BUG in emx runtime

Hardy Griech (rgriech@ibm.net)
Sun, 22 Sep 1996 13:11:43 +0200

I have detected a somehow strange bug in the emx runtime (tested with
the revisions 40 and 50)!

Check the following loop:

for (;;) {
++msgCounter;
sprintf( fname, "%08d.msg",msgCounter );
if ((msgF = fopen(fname, "wb")) != NULL)
break;
#ifdef TEST
if (errno != EACCES) { // catch 'not enough file handles'
perror( fname );
exit( EXIT_FAILURE );
}
#endif
}

Intention of the loop is, to create an open file for writing, but
skipping files which couldn't be opened (e.g. write protected).

Let's assume the number of file handles has been exceeded, which means
fopen() will return with NULL (BTW we have compiled with -UTEST). The
result is clear: an endless loop doing almost nothing (incrementing
msgCounter, trying a fopen()).

BUT: The actual result is, that an endless number of files are
created, which means that a failed fopen() is generating a file, which
should be considered as a bug of the runtime.

After detecting the problem, I had a look into the sources of the
runtime (BTW emx09a). It showed:

----------------------------------------
/* fopen.c (emx+gcc) -- Copyright (c) 1990-1993 by Eberhard Mattes */

#include <sys/emx.h>
#include <stdio.h>
#include <share.h>

FILE *fopen (const char *fname, const char *mode)
{
FILE *f;

f = _newstream ();
if (f != NULL)
f = _fopen (f, fname, mode, SH_DENYNO);
return (f);
}
----------------------------------------

Now I am a little bit confused, because this version would/should not
create a file, if there is no handle available. Or are the newer
runtimes different in this area and a new bug was introduced?

Anyway, a failed fopen() should not leave a created file on the HDD!

-- 
Hardy Griech, Kurt-Schumacher-Str. 25/1, D-72762 Reutlingen