labb-4ac@e260-2a.berkeley.edu (superMan (the web dweller)) (11/27/90)
I have the following FILE *fp[256]; for(i=0;i!=256;i++) fp[i]=fopen(file_name[i],"r+"); but when I look at the value of fp[i] I get (nil) O d.n.a.b. aNime bERkeley 3x3 Sazan Eyes Project o o Q: What do you call a new cyborg? A: A baby boomer.
bhoughto@cmdnfs.intel.com (Blair P. Houghton) (11/28/90)
In article <1990Nov27.131327.21662@agate.berkeley.edu> labb-4ac@e260-2a.berkeley.edu (superMan (the web dweller)) writes: >I have the following > >FILE *fp[256]; > >for(i=0;i!=256;i++) fp[i]=fopen(file_name[i],"r+"); > >but when I look at the value of fp[i] I get (nil) How big is `i'? If it's over 63, you're likely to have a problem. On older machines, the maximum is 19 (i.e., only 20 file descriptors allowed). 1. Find out what standard header file on your system defines the number of file descriptors you may use. (Usually it will be defined in stdio.h). 2. Find out what the macro is called (Under Ultrix 3.1 it's _NFILE). 3. Include the header. 4. Replace `256' with the macro everywhere. 5. Avoid trying to access beyond the end of the array (on some systems it's a core-dumping segmentation violation). There's nothing wrong with using an array of file pointers instead of unarrayed file pointers. --Blair "Currently working on an in-circuit emulator for the Milton-Bradley game, 'Operation.' Bzzzt! :-)"
gwyn@smoke.brl.mil (Doug Gwyn) (11/28/90)
In article <1990Nov27.131327.21662@agate.berkeley.edu> labb-4ac@e260-2a.berkeley.edu (superMan (the web dweller)) writes: >FILE *fp[256]; >for(i=0;i!=256;i++) fp[i]=fopen(file_name[i],"r+"); >but when I look at the value of fp[i] I get (nil) Well, why not? fopen() is entitled to fail. And it probably will if you try to have too many files open at the same time.
wirzeniu@cs.Helsinki.FI (Lars Wirzenius) (11/28/90)
In article <1990Nov27.131327.21662@agate.berkeley.edu> labb-4ac@e260-2a.berkeley.edu (superMan (the web dweller)) writes: >FILE *fp[256]; >for(i=0;i!=256;i++) fp[i]=fopen(file_name[i],"r+"); >but when I look at the value of fp[i] I get (nil) I think the problem is that you've hit on the maximum number of open files per program in your system. The limit may be set by either the operating system, the C library or both. For example, on MS-DOS using Turbo C the limit is 20 open files at once. In ANSI-systems the macro FOPEN_MAX (defined in <stdio.h>) tells the maximum number of files that you can have open simultaneously. You can try to get around this by keeping the files open only when you need them. You might want to save the "current place" before you close a file, and restore it after you re-open it. Lars Wirzenius wirzeniu@cs.helsinki.fi wirzenius@cc.helsinki.fi
weimer@ssd.kodak.com (Gary Weimer) (11/28/90)
In article <1990Nov27.131327.21662@agate.berkeley.edu> labb-4ac@e260-2a.berkeley.edu (superMan (the web dweller)) writes: >I have the following > >FILE *fp[256]; > >for(i=0;i!=256;i++) fp[i]=fopen(file_name[i],"r+"); > >but when I look at the value of fp[i] I get (nil) As others have mentioned, you are probably getting (nil) because fopen() is failing (most likely because you are opening too many files). If you want to know the specific reason for the failure, or just be notified when such a failure occurs, try using: for(i=0;i!=256;i++) if ((fp[i]=fopen(file_name[i],"r+")) <= 0) /* some will probably */ /* complain about using */ /* <= 0 comparison */ { perror("Error opening file"); /* this will print: */ /* "Error opening file: REASON" */ /* put error handler here, or just exit program */ }
gwyn@smoke.brl.mil (Doug Gwyn) (11/29/90)
In article <1990Nov28.152146.19560@ssd.kodak.com> weimer@ssd.kodak.com (Gary Weimer) writes: > if ((fp[i]=fopen(file_name[i],"r+")) <= 0) > perror("Error opening file"); Please don't do this; on UNIX, perror() will report the reason for the last SYSTEM CALL failure, not the reason for failure of a library routine such as fopen(). Sometimes there is a close relation between these but at other times there is not, leading to such absurd diagnostics as "Error opening file: not a tty".
donm@margot.Eng.Sun.COM (Don Miller) (11/29/90)
In article <1990Nov27.131327.21662@agate.berkeley.edu> labb-4ac@e260-2a.berkeley.edu (superMan (the web dweller)) writes: >I have the following > >FILE *fp[256]; > >for(i=0;i!=256;i++) fp[i]=fopen(file_name[i],"r+"); > >but when I look at the value of fp[i] I get (nil) Interesting threads regarding maximum open files notwithstanding, it seems that a simple answer to the original question posed is the mode is wrong. If the files to be opened do not exist prior to the fopen call, using fopen with "r+" will return 0 (nil, NULL). Try "w+" to open a new file for update. Since "w+" overwrites files, you'll want to be careful. You may want to use what you have to verify the non-existence before you use "w+". -- Don Miller | #include <std.disclaimer> Software Quality Engineering | #define flame_retardent \ Sun Microsystems, Inc. | "I know you are but what am I?" donm@eng.sun.com |
kimcm@rimfaxe.diku.dk (Kim Christian Madsen) (11/29/90)
weimer@ssd.kodak.com (Gary Weimer) writes: >for(i=0;i!=256;i++) > if ((fp[i]=fopen(file_name[i],"r+")) <= 0) /* some will probably */ > /* complain about using */ > /* <= 0 */ YES, for more than one reason: 1) fopen returns a FILE * and should be tested against the constant NULL, or (FILE *) NULL if you want explicit casting. 2) If the pointer returned by fopen points to a memory location in the high end it is very possible that when converted to an int for the comparison it will be negative. Kim Chr. Madsen
dold@mitisft.Convergent.COM (Clarence Dold) (11/30/90)
in article <14603@smoke.brl.mil>, gwyn@smoke.brl.mil (Doug Gwyn) says: > In article <1990Nov28.152146.19560@ssd.kodak.com> weimer@ssd.kodak.com (Gary Weimer) writes: >> if ((fp[i]=fopen(file_name[i],"r+")) <= 0) >> perror("Error opening file"); > Please don't do this; on UNIX, perror() will report the reason for the last > SYSTEM CALL failure, not the reason for failure of a library routine such as Quoth my man page, perror(3c): "... last error encountered during a call to a system or library function..." The most common coding error in this area is to check errno after calling a function, without checking for an error return from the function, resulting in retrieval of some earlier errno, not associated with more recent calls. -- --- Clarence A Dold - dold@tsmiti.Convergent.COM (408) 435-5293 ...pyramid!ctnews!tsmiti!dold FAX (408) 435-3105 P.O.Box 6685, San Jose, CA 95150-6685 MS#10-007