f



fopen problem - straight C program on OS Lion, Xcode 4.3.2 - whazzup?

A skeleton program which is supposed to open a text file (created by
Wrangler so it's unicode but w/ unix lf breaks) and read a line and print it.
he file exists in the location as specified in the code,
which is below. The build succeeded w/o error. It's prob. some stupid typo
but I can't see it.

Regards,

ken quirici

here's the output returned:

fopen failed
my_ret = -1

Here's the code as copied from the Xcode editor.

//
//  main.c
//  encode
//
//  Created by ken quirici on 6/16/12.
//  Copyright (c) 2012 __MyCompanyName__. All rights reserved.
//

#include <stdio.h>

int main(int argc, const char * argv[])
{
    char *my_filename;
    char *my_mode;
    char next_line[1000000];
    int my_ret,max_line;
    
    my_filename = "/Users/kenquirici/Desktop/journal/journal.txt.save";
    my_mode = "r";
    max_line = 1000000;
//    next_line = "";
//    my_ret_line = "";
    
    FILE *my_file;
    
    if((my_file = fopen(my_filename,my_mode)) == NULL)
        printf("fopen failed\n");
    else if(fgets(next_line,max_line,my_file) == NULL)
       printf("fgets returned null\n");
    else
       printf("%s%s","next_line: ",next_line);
    
    my_ret = fclose(my_file);

    // insert code here...
    printf("%s%d%s","my_ret = ",my_ret,"\n");
    return 0;
}



0
kquirici
6/17/2012 2:55:56 PM
comp.sys.mac.programmer.help 4653 articles. 2 followers. Post Follow

7 Replies
817 Views

Similar Articles

[PageSpeed] 22

"kquirici@yahoo.com" <kquirici@yahoo.com> writes:

> A skeleton program which is supposed to open a text file (created by
> Wrangler so it's unicode but w/ unix lf breaks) and read a line and print it.
> he file exists in the location as specified in the code,
> which is below. The build succeeded w/o error. It's prob. some stupid typo
> but I can't see it.
>
> Regards,
>
> ken quirici
>
> here's the output returned:
>
> fopen failed
> my_ret = -1
>
> Here's the code as copied from the Xcode editor.
>
> //
> //  main.c
> //  encode
> //
> //  Created by ken quirici on 6/16/12.
> //  Copyright (c) 2012 __MyCompanyName__. All rights reserved.
> //
>
> #include <stdio.h>
>
> int main(int argc, const char * argv[])
> {
>     char *my_filename;
>     char *my_mode;
>     char next_line[1000000];
>     int my_ret,max_line;
>     
>     my_filename = "/Users/kenquirici/Desktop/journal/journal.txt.save";
>     my_mode = "r";
>     max_line = 1000000;
> //    next_line = "";
> //    my_ret_line = "";
>     
>     FILE *my_file;
>     
>     if((my_file = fopen(my_filename,my_mode)) == NULL)
>         printf("fopen failed\n");

Use perror() instead of printf, so you can see why the file couldn't be
opened, e.g.:

  perror(my_filename);

>     else if(fgets(next_line,max_line,my_file) == NULL)
>        printf("fgets returned null\n");
>     else
>        printf("%s%s","next_line: ",next_line);

That's a really bizarre way to use printf.  Why not:

  printf("next_line: %s", next_line);

>     my_ret = fclose(my_file);

Calling fclose() on a null pointer (as you do in the error case) is a
bug.

>     // insert code here...
>     printf("%s%d%s","my_ret = ",my_ret,"\n");
>     return 0;
> }

-- 
http://www.greenend.org.uk/rjk/
0
Richard
6/17/2012 3:14:59 PM
On Sunday, June 17, 2012 11:14:59 AM UTC-4, Richard Kettlewell wrote:
> "kquirici@yahoo.com" <kquirici@yahoo.com> writes:
> 
> > A skeleton program which is supposed to open a text file (created by
> > Wrangler so it's unicode but w/ unix lf breaks) and read a line and print it.
> > he file exists in the location as specified in the code,
> > which is below. The build succeeded w/o error. It's prob. some stupid typo
> > but I can't see it.
> >
> > Regards,
> >
> > ken quirici
> >
> > here's the output returned:
> >
> > fopen failed
> > my_ret = -1
> >
> > Here's the code as copied from the Xcode editor.
> >
> > //
> > //  main.c
> > //  encode
> > //
> > //  Created by ken quirici on 6/16/12.
> > //  Copyright (c) 2012 __MyCompanyName__. All rights reserved.
> > //
> >
> > #include <stdio.h>
> >
> > int main(int argc, const char * argv[])
> > {
> >     char *my_filename;
> >     char *my_mode;
> >     char next_line[1000000];
> >     int my_ret,max_line;
> >     
> >     my_filename = "/Users/kenquirici/Desktop/journal/journal.txt.save";
> >     my_mode = "r";
> >     max_line = 1000000;
> > //    next_line = "";
> > //    my_ret_line = "";
> >     
> >     FILE *my_file;
> >     
> >     if((my_file = fopen(my_filename,my_mode)) == NULL)
> >         printf("fopen failed\n");
> 
> Use perror() instead of printf, so you can see why the file couldn't be
> opened, e.g.:
> 
>   perror(my_filename);
> 
> >     else if(fgets(next_line,max_line,my_file) == NULL)
> >        printf("fgets returned null\n");
> >     else
> >        printf("%s%s","next_line: ",next_line);
> 
> That's a really bizarre way to use printf.  Why not:
> 
>   printf("next_line: %s", next_line);
> 
> >     my_ret = fclose(my_file);
> 
> Calling fclose() on a null pointer (as you do in the error case) is a
> bug.
> 
> >     // insert code here...
> >     printf("%s%d%s","my_ret = ",my_ret,"\n");
> >     return 0;
> > }
> 
> -- 
> http://www.greenend.org.uk/rjk/

ok I'll try perror. Thx for that & the other suggestions.

Regards

ken quirici
0
kquirici
6/17/2012 3:38:08 PM
On Sunday, June 17, 2012 11:14:59 AM UTC-4, Richard Kettlewell wrote:
> "kquirici@yahoo.com" <kquirici@yahoo.com> writes:
> 
> > A skeleton program which is supposed to open a text file (created by
> > Wrangler so it's unicode but w/ unix lf breaks) and read a line and print it.
> > he file exists in the location as specified in the code,
> > which is below. The build succeeded w/o error. It's prob. some stupid typo
> > but I can't see it.
> >
> > Regards,
> >
> > ken quirici
> >
> > here's the output returned:
> >
> > fopen failed
> > my_ret = -1
> >
> > Here's the code as copied from the Xcode editor.
> >
> > //
> > //  main.c
> > //  encode
> > //
> > //  Created by ken quirici on 6/16/12.
> > //  Copyright (c) 2012 __MyCompanyName__. All rights reserved.
> > //
> >
> > #include <stdio.h>
> >
> > int main(int argc, const char * argv[])
> > {
> >     char *my_filename;
> >     char *my_mode;
> >     char next_line[1000000];
> >     int my_ret,max_line;
> >     
> >     my_filename = "/Users/kenquirici/Desktop/journal/journal.txt.save";
> >     my_mode = "r";
> >     max_line = 1000000;
> > //    next_line = "";
> > //    my_ret_line = "";
> >     
> >     FILE *my_file;
> >     
> >     if((my_file = fopen(my_filename,my_mode)) == NULL)
> >         printf("fopen failed\n");
> 
> Use perror() instead of printf, so you can see why the file couldn't be
> opened, e.g.:
> 
>   perror(my_filename);
> 
> >     else if(fgets(next_line,max_line,my_file) == NULL)
> >        printf("fgets returned null\n");
> >     else
> >        printf("%s%s","next_line: ",next_line);
> 
> That's a really bizarre way to use printf.  Why not:
> 
>   printf("next_line: %s", next_line);
> 
> >     my_ret = fclose(my_file);
> 
> Calling fclose() on a null pointer (as you do in the error case) is a
> bug.
> 
> >     // insert code here...
> >     printf("%s%d%s","my_ret = ",my_ret,"\n");
> >     return 0;
> > }
> 
> -- 
> http://www.greenend.org.uk/rjk/

well that's weird. when I replaced the printf(....my_ret...)
with perror(my_filename)

it now works - it returns the first line of the file whose name is
my_filename. That is, fopen is no longer returning null, apparently.

I tried running it again just now exactly as before and again it worked.

I'm going to see if I can read the whole file in.

I am very confused. I can only think that some previous run left the file
open, so when I tried to fopen it it failed because it was already open.
But that run where the fopen failed, the fclose must have worked (because it
was already open). That make sense?

Regards,

Ken Quirici

On Sunday, June 17, 2012 11:14:59 AM UTC-4, Richard Kettlewell wrote:
> "kquirici@yahoo.com" <kquirici@yahoo.com> writes:
> 
> > A skeleton program which is supposed to open a text file (created by
> > Wrangler so it's unicode but w/ unix lf breaks) and read a line and print it.
> > he file exists in the location as specified in the code,
> > which is below. The build succeeded w/o error. It's prob. some stupid typo
> > but I can't see it.
> >
> > Regards,
> >
> > ken quirici
> >
> > here's the output returned:
> >
> > fopen failed
> > my_ret = -1
> >
> > Here's the code as copied from the Xcode editor.
> >
> > //
> > //  main.c
> > //  encode
> > //
> > //  Created by ken quirici on 6/16/12.
> > //  Copyright (c) 2012 __MyCompanyName__. All rights reserved.
> > //
> >
> > #include <stdio.h>
> >
> > int main(int argc, const char * argv[])
> > {
> >     char *my_filename;
> >     char *my_mode;
> >     char next_line[1000000];
> >     int my_ret,max_line;
> >     
> >     my_filename = "/Users/kenquirici/Desktop/journal/journal.txt.save";
> >     my_mode = "r";
> >     max_line = 1000000;
> > //    next_line = "";
> > //    my_ret_line = "";
> >     
> >     FILE *my_file;
> >     
> >     if((my_file = fopen(my_filename,my_mode)) == NULL)
> >         printf("fopen failed\n");
> 
> Use perror() instead of printf, so you can see why the file couldn't be
> opened, e.g.:
> 
>   perror(my_filename);
> 
> >     else if(fgets(next_line,max_line,my_file) == NULL)
> >        printf("fgets returned null\n");
> >     else
> >        printf("%s%s","next_line: ",next_line);
> 
> That's a really bizarre way to use printf.  Why not:
> 
>   printf("next_line: %s", next_line);
> 
> >     my_ret = fclose(my_file);
> 
> Calling fclose() on a null pointer (as you do in the error case) is a
> bug.
> 
> >     // insert code here...
> >     printf("%s%d%s","my_ret = ",my_ret,"\n");
> >     return 0;
> > }
> 
> -- 
> http://www.greenend.org.uk/rjk/

0
kquirici
6/17/2012 3:53:21 PM
On Sunday, June 17, 2012 11:14:59 AM UTC-4, Richard Kettlewell wrote:
> "kquirici@yahoo.com" <kquirici@yahoo.com> writes:
> 
> > A skeleton program which is supposed to open a text file (created by
> > Wrangler so it's unicode but w/ unix lf breaks) and read a line and print it.
> > he file exists in the location as specified in the code,
> > which is below. The build succeeded w/o error. It's prob. some stupid typo
> > but I can't see it.
> >
> > Regards,
> >
> > ken quirici
> >
> > here's the output returned:
> >
> > fopen failed
> > my_ret = -1
> >
> > Here's the code as copied from the Xcode editor.
> >
> > //
> > //  main.c
> > //  encode
> > //
> > //  Created by ken quirici on 6/16/12.
> > //  Copyright (c) 2012 __MyCompanyName__. All rights reserved.
> > //
> >
> > #include <stdio.h>
> >
> > int main(int argc, const char * argv[])
> > {
> >     char *my_filename;
> >     char *my_mode;
> >     char next_line[1000000];
> >     int my_ret,max_line;
> >     
> >     my_filename = "/Users/kenquirici/Desktop/journal/journal.txt.save";
> >     my_mode = "r";
> >     max_line = 1000000;
> > //    next_line = "";
> > //    my_ret_line = "";
> >     
> >     FILE *my_file;
> >     
> >     if((my_file = fopen(my_filename,my_mode)) == NULL)
> >         printf("fopen failed\n");
> 
> Use perror() instead of printf, so you can see why the file couldn't be
> opened, e.g.:
> 
>   perror(my_filename);
> 
> >     else if(fgets(next_line,max_line,my_file) == NULL)
> >        printf("fgets returned null\n");
> >     else
> >        printf("%s%s","next_line: ",next_line);
> 
> That's a really bizarre way to use printf.  Why not:
> 
>   printf("next_line: %s", next_line);
> 
> >     my_ret = fclose(my_file);
> 
> Calling fclose() on a null pointer (as you do in the error case) is a
> bug.
> 
> >     // insert code here...
> >     printf("%s%d%s","my_ret = ",my_ret,"\n");
> >     return 0;
> > }
> 
> -- 
> http://www.greenend.org.uk/rjk/

well it now works. It read in the whole file and printed out each line.
I can move to the next step in my little project whose purpose is probably
clear from the name of this program :-)

Thanks & Regards,

Ken Quirici
0
kquirici
6/17/2012 3:54:37 PM
"kquirici@yahoo.com" <kquirici@yahoo.com> writes:
> well that's weird. when I replaced the printf(....my_ret...)
> with perror(my_filename)
>
> it now works - it returns the first line of the file whose name is
> my_filename. That is, fopen is no longer returning null, apparently.
>
> I tried running it again just now exactly as before and again it worked.
>
> I'm going to see if I can read the whole file in.
>
> I am very confused. I can only think that some previous run left the file
> open, so when I tried to fopen it it failed because it was already open.
> But that run where the fopen failed, the fclose must have worked (because it
> was already open). That make sense?

No, it doesn't.  You can still open files even if something else has
them open, and fclose() only does anything useful for open streams (like
I said, fclose(NULL) is never right).

Presumably something else changed that you didn't notice.

-- 
http://www.greenend.org.uk/rjk/
0
Richard
6/17/2012 5:00:03 PM
On Sunday, June 17, 2012 1:00:03 PM UTC-4, Richard Kettlewell wrote:
> "kquirici@yahoo.com" <kquirici@yahoo.com> writes:
> > well that's weird. when I replaced the printf(....my_ret...)
> > with perror(my_filename)
> >
> > it now works - it returns the first line of the file whose name is
> > my_filename. That is, fopen is no longer returning null, apparently.
> >
> > I tried running it again just now exactly as before and again it worked.
> >
> > I'm going to see if I can read the whole file in.
> >
> > I am very confused. I can only think that some previous run left the file
> > open, so when I tried to fopen it it failed because it was already open.
> > But that run where the fopen failed, the fclose must have worked (because it
> > was already open). That make sense?
> 
> No, it doesn't.  You can still open files even if something else has
> them open, and fclose() only does anything useful for open streams (like
> I said, fclose(NULL) is never right).
> 
> Presumably something else changed that you didn't notice.
> 
> -- 
> http://www.greenend.org.uk/rjk/

ok, well that's good to know. More attention is req'd than I thought
necessary. That's good to know.

Thanks & Regards,

Ken Quirici
0
kquirici
6/17/2012 8:12:58 PM
In article 
<16694ec6-4819-4355-a10d-df1e7df3e337@googlegroups.com>,
 "kquirici@yahoo.com" <kquirici@yahoo.com> wrote:

> > http://www.greenend.org.uk/rjk/
> 
> well that's weird. when I replaced the printf(....my_ret...)
> with perror(my_filename)
> 
> it now works - it returns the first line of the file whose name is
> my_filename. That is, fopen is no longer returning null, apparently.
> 
> I tried running it again just now exactly as before and again it worked.
> 
> I'm going to see if I can read the whole file in.
> 
> I am very confused. I can only think that some previous run left the file
> open, so when I tried to fopen it it failed because it was already open.
> But that run where the fopen failed, the fclose must have worked (because it
> was already open). That make sense?

A user mode program no matter how it exists will ALWAYS release 
any memory it is using, and it will automatically close any open 
files.  A file opened by another independent program or a previous 
run of the same program will never leave a file open for a future 
program to use.  A program gets to open its own files if it wants 
to use them.

The one except to the opening a file rule is if a process fork()'s 
a child process.  The child process can inherit an open file from 
the parent and they can both share that open file's current access 
point.  A parent can fork() as many times as it wants (within the 
limits of the system it is running on) and each child will inherit 
the current open files.  A child can fork() and pass along the 
open files it inherited from its parent to its child (wash, rinse, 
repeat as much as the task at hand needs).  Any process sharing 
that open can close its handle/file descriptor and it will not 
affect the other opens.

As I just mentioned, an open file inherited from its parent will 
share the open file's current access point.  This means a read 
(using a file descriptor, which is different from a FILE *handle) 
by the parent or any of the children, grandchildren, great 
grandchildren, etc... will move the current access point, such 
that the next read from any of the other opens will read from the 
updated file access point.  The same is true for writes to the 
file descriptor.

HOWEVER, a FILE *handle is semi-private, in that the open file 
descriptor is buried in the handle, but the buffer used by the 
handle is specific to the handle in the private memory of the 
process, as well as the handle's idea of where it is in the file.

All in all, while the fact that inherited opens share the current 
file descriptor access point is a cool feature, there are very few 
uses for this and generally if a parent passes an open file to a 
child, the parent generally does not touch the file until the 
child terminates to avoid problems for either side.

This is a lot more than you ever wanted to know about Linux/Unix 
(which includes Mac OS X) I/O primitive operations. 

> Regards,
> 
> Ken Quirici
0
Bob
6/19/2012 2:30:31 AM
Reply: