Re: Is this a bug in libc6?
On 11-Apr-98, 02:26 (CDT), Manoj Srivastava <srivasta@datasync.com> wrote:
> So, the point is not whether they implemntation can do strange
> and unexpected things; they can; but then they have to document it.
>
> BTW, in Debian, fclose says it returns an error, and does not mention
> corrupting memory.
> ERRORS
> EBADF The argument stream is not an open stream.
>
> The fclose function may also fail and set errno for any of
> the errors specified for the routines close(2) or
> fflush(3).
Oh, sure, that's an error it *may* report, *if* it detects it. I don't
see anything on the man page that would expect me to believe that the
implementation will detect all possible invalid streams and report an
error. I am also quite willing to believe that the particular error we
are discussing (fclose(fp);fclose(fp)) will be detected.
Unfortunately, that belief is not supported. Consider the
program:
#include <stdio.h>
int
main (void)
{
FILE *fp;
if ((fp = fopen ("test.dat", "w")) == NULL)
{
printf ("Failed to open test.dat\n");
}
printf ("open succeed\n");
if (fclose (fp) != 0)
{
perror ("#1 says:");
}
printf ("fclose #1 succeed\n");
if (fclose (fp) != 0)
{
perror ("#2 says:");
}
printf ("fclose #2 succeed\n");
return 0;
}
Compile with:
cc -g -Wall -o testclose testclose.c
The output is:
open succeed
fclose #1 succeed
Segmentation fault (core dumped)
(All the above on a hamm system that was up-to-date as of April 9th.)
While something better would be nice, I consider this completely ISO
C compliant. I can imagine a nice debugging stdio lib, the equivalent
of electric-fence or some such, which kept track of valid streams and
validated everything before use, etc etc. I'd also hate to pay the price
of those checks on a release build.
Steve
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: