From owner-freebsd-questions  Sun Jun  6 23: 7:46 1999
Delivered-To: freebsd-questions@freebsd.org
Received: from ds9.dreamhaven.org (dt0f4nfc.san.rr.com [24.94.22.252])
	by hub.freebsd.org (Postfix) with ESMTP id DA42714D88
	for <freebsd-questions@freebsd.org>; Sun,  6 Jun 1999 23:07:43 -0700 (PDT)
	(envelope-from data@ds9.dreamhaven.org)
Received: from data (helo=localhost)
	by ds9.dreamhaven.org with local-esmtp (Exim 2.12 #2)
	id 10qsZS-00073I-00; Sun, 6 Jun 1999 23:07:42 -0700
Date: Sun, 6 Jun 1999 23:07:42 -0700 (PDT)
From: Bryce Newall <data@dreamhaven.net>
To: FreeBSD Questions List <freebsd-questions@freebsd.org>
Cc: trv@dreamhaven.net
Subject: Possible C library bug?
Message-ID: <Pine.NEB.4.10.9906062301420.99176-100000@ds9.dreamhaven.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-questions@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Greetings!

One of my users recently brought to my attention a possible bug in either
the FreeBSD C compilers (cc and gcc), or one of the libraries.  The bug
has to do with attempting to close a file that was never successfully
opened.  In other words, with a statement something like:

  f = fopen("filename", "r");

If the fopen fails, for whatever reason, and f has a value of NULL, then
this statement:

  flose(f);

will return a segmentation fault, instead of simply not doing anything.

Here is a piece of code that he wrote to test it:

include <stdio.h>

/* Purpose: to test how fclose() handles NULL pointers.
*/

void main() {
  int iStat;
  FILE *fp;
  char szLine[BUFSIZ];

  fp = fopen("doesnotexist.file", "r");

  if (!fp) {
    iStat = fclose(fp);
  } else {
    fgets(szLine, BUFSIZ, fp);
    iStat = fclose(fp);
  }
}

I logged into his account, and performed the following tests:  (The file
above is the one called testgcc.c)

trv@calico:/home/trv/src>% cc -o testcc testgcc.c
trv@calico:/home/trv/src>% gcc -o testgcc testgcc.c
trv@calico:/home/trv/src>% ./testcc
Segmentation fault (core dumped)
trv@calico:/home/trv/src>% ./testgcc
Segmentation fault (core dumped)
trv@calico:/home/trv/src>% uname -a
FreeBSD calico.dreamhaven.net 3.1-STABLE FreeBSD 3.1-STABLE #4: Thu May 13
16:50:23 MDT 1999
root@calico.dreamhaven.net:/usr/src/sys/compile/CALICO  i386

As you can see, the program dumped core both with cc and gcc.  I made the
same test on a Linux system:

bahamut:/root# cc -o testcc testgcc.c
bahamut:/root# gcc -o testgcc testgcc.c
bahamut:/root# ./testcc
bahamut:/root# ./testgcc
bahamut:/root# uname -a
Linux bahamut 2.0.35 #5 Sun Dec 13 08:57:24 EST 1998 i586

No problem there.  Same thing with a Solaris machine, aside from a gcc
compiler warning:

[9]newall@rohan:/home/ma/t/newall % cc -o testcc testgcc.c
[10]newall@rohan:/home/ma/t/newall % gcc -o testgcc testgcc.c
testgcc.c: In function `main':
testgcc.c:6: warning: return type of `main' is not `int'
[11]newall@rohan:/home/ma/t/newall % ./testcc
[12]newall@rohan:/home/ma/t/newall % ./testgcc
[13]newall@rohan:/home/ma/t/newall % uname -a
SunOS rohan 5.6 Generic_105181-14 sun4u sparc SUNW,Ultra-Enterprise

Perhaps there's a compiler flag that is required under FreeBSD, but not
under these other OS's?  Or do you think this may indeed be a bug?

Thanks for your time!

**********************************************************************
*       Bryce Newall       *       Email: data@dreamhaven.net        *
*     WWW: http://www.dreamhaven.net/~data    *    ICQ: 32620929     *
*       "Insanity takes its toll.  Please have exact change."        *
**********************************************************************



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message