Re: fopen
Re: fopen
- Subject: Re: fopen
- From: Conrad Shultz <email@hidden>
- Date: Mon, 02 Jul 2012 12:15:36 -0700
On 07/02/2012 10:11 AM, rckrueger wrote:
> I am just learning c, and this is a beginner's question. I am using
> Xcode 4 (Command Line tool) to create a program that will read a simple
> text file (a number 1234). When I use the code:
>
>
> #include <stdio.h>
>
> int main(int argc, const char * argv[])
> {FILE*inputfile;// a pointer to the input file
> inputfile = fopen("test.txt", "r");
>
>
> to find and open the test.txt file which I have in the Project folder,
> same level as the main.c file, I get the error message:
>
> Thread 1: EXC_BAD_ACCESS (code=1, address=0x68
>
> which I guess means that it can't find the file.
This isn't a C mailing list; you probably should head over to
StackOverflow to ask general programming questions.
However, since I'm already replying, I will give a few potential insights.
EXC_BAD_ACCESS occurs, in general terms, when you try to access invalid
memory.
fopen() should return NULL if there's an error. From "man fopen":
"Upon successful completion fopen(), fdopen(), and freopen() return a
FILE pointer. Otherwise, NULL is returned and the global variable errno
is set to indicate the error."
Your call to fopen() will not cause this crash. My guess is that you
failed subsequently to check whether fopen() returned a valid pointer
(e.g. if (inputfile) {}) and just started using it as if it had. This
subsequent usage caused the crash (what is termed a "null pointer
dereference").
Never assume that function calls, particularly to I/O functions like
fopen(), were successful! (I realize that you are just beginning C, so
I want to drive this home early.)
> When I use this line to look for the file on the desktop:
>
> inputfile = fopen("/users/robertkruegertiger/desktop/test.txt", "r");
> the program works as expected.
>
> How do I get the program to find the test.txt file in the Project
> folder. I have already used the "Add Files to FileReadExample..", which
> copied it from the Desktop folder to the same folder as the main.c code.
> What more needs to be done? TIA
OK, this is a little more Xcode-ish. The problem you are likely running
into is that Xcode does a lot of stuff "behind the scenes" that goes
beyond what you might do manually at the command line (i.e. "gcc -o
MyProgram MyProgram.c"). In particular, one of your project settings
(click on the project in the navigator, then click on "Build Settings")
dictates the location of the built product. This is *not* generally the
same location as the source files, especially in Xcode 4.
It's been a while since I looked at the Command Line Tool template so I
don't remember how Xcode handles copying non-source files into the
destination. In Cocoa applications you can have such files included in
the application bundle, but in your case there is no bundle, so I'm not
sure what's going to happen.
Your best bet is to find out the file location at run-time. This will
let you have a more flexible (i.e. useful) application and will give you
good practice working with input and C strings.
Two common approaches are to take a file name as a command line argument
(look up those argc and argv variables!) that you can, in Xcode, set as
a setting in your scheme, or to have an interactive prompt for the file
name, which you will be able to see in the Xcode console (left as an
exercise to the reader).
> postscript: And when the program finds the file and works properly,
> will it automatically write subsequent files in the same folder?
>
No, the low-level stdio functions, such as fopen(), fread(), etc. are
going to need hand-holding at every stage.
FWIW, I understand you are doing this as a learning exercise, but just
know that (assuming you are targeting OS X only) when you go to write
real applications, you will likely have a more enjoyable and productive
development process if you start using Objective-C and
Foundation.framework, even for command line tools. Most of these
specific issues will still apply, but you will generally have fewer hard
crashes, more descriptive error messages, and can avoid a great many
subtle mistakes that are common in straight C.
Others might suggest using C++, which has a number of support libraries
that can be of assistance, but I'm an Objective-C man myself. :-)
--
Conrad Shultz
Synthetiq Solutions
www.synthetiqsolutions.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
| References: | |
| | >fopen (From: rckrueger <email@hidden>) |