Path: utzoo!attcan!uunet!jarthur!usc!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!ucsd!sdcc6!sdcc10!cs163wau
From: cs163wau@sdcc10.ucsd.edu (Tyron)
Newsgroups: comp.lang.c
Subject: Re: fopen
Message-ID: <7092@sdcc6.ucsd.edu>
Date: 8 Feb 90 01:14:49 GMT
References: <6307@sdcc6.ucsd.edu> <175@pride38.UUCP>
Sender: news@sdcc6.ucsd.edu
Organization: University of California, San Diego
Lines: 58


>In article <6307@sdcc6.ucsd.edu>, cs161fdu@sdcc10.ucsd.edu (Don't crash sdcc10) writes:
>> 
>> int function()
>> {
>> FILE *fp;
>> fp=fopen("Anyfile","r"0;); //where "Anyfile" can be anyfile: ie.  test.data
>> return something;
>> }
>> 
>> Gary (cs161fdu)

The problem was with fopened calling a predefined open function.  My routine
was also called open.

 fp=fopen("Anyfile","r"0;); //where "Anyfile" can be anyfile: ie.  test.data
                       ^^
                       | does not belong there.  A typo during message entry.


---------------------------------------------------------------------
> Subject: fopen

Gary,

> Is there a reason why fopen will not work in my subroutines that are in a 
> different file? fopen works when it is contained in the main program, but
> when I put a routine containing fopen in a separate file, statements coming
> after the fopen statements are never reached.  Once fopen is reached, the
> routine seems to start over again.  I've check the code and everything is
> correct to my knowledge.

This is a shot in the dark.  Do you happen to have a function named
"open" somewhere in your program?  Maybe the very function containing the
call to "fopen"?  If you are not using an ANSI-conforming implementation
of C, this is likely to cause a problem.

The reason is that "fopen" may call other functions to do its work.
The names of those other functions may collide with names of your own
functions, causing your functions to be called instead of the ones
fopen wants.  The most likely culprit for a name clash when calling
"fopen" is "open".

This is called the "name space pollution" problem and is common
in pre-ANSI systems.  There is no way a programmer can be expected
to anticipate what names have to be avoided.  ANSI C solves the
problem by defining what names are allowed to be used by the
C library; all other names belong to the programmer.

Walter Murray
Hewlett-Packard, C language project
----------------------------------------------------------------------

Although I figured out the problem, I would like to thank Walter and
others who have written to me about this problem.


Gary (cs161fdu@sdcc10.ucsd.edu)