Thread: FILE* question

  1. #1
    Registered User
    Join Date
    Aug 2007
    Posts
    81

    FILE* question

    I really don't get why I can't pass a FILE* to a function, have that function call fopen on that FILE*, and return to the caller with the FILE* still holding the address of the file object.


    Code:
    	FILE* inFile = 0;
            openNextFile(inFile, argv[fileIndex], &fileIndex, argc);
    
    
    /* definition */
    int openNextFile(FILE* inFile, char* fileName, int* fileIndex) {
    	inFile = fopen(fileName, "rb");
    	(*fileIndex)++;
    	if ( NULL == inFile ) {
    		return FAILED;
    	}
    	return SUCCESS;	
    }
    the call to fopen is successful, and the return status is SUCCESS, yet inFile becomes NULL after the function returns.

  2. #2
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Of course it does! The compiler creates a copy of your FILE* argument when passing to the function, hence it won't reflect the changes after the function call. You need to use a pointer for that - and in this case a pointer to a pointer, FILE**.

  3. #3
    Registered User
    Join Date
    Aug 2007
    Posts
    81
    Thanks Elysia, I was able to figure out that it's really:

    Code:
    FILE* inFile = 0;
            openNextFile(&inFile, argv[fileIndex], &fileIndex, argc);
    
    
    /* definition */
    int openNextFile(FILE** inFile, char* fileName, int* fileIndex) {
    	*inFile = fopen(fileName, "rb");
    	(*fileIndex)++;
    	if ( NULL == inFile ) {
    		return FAILED;
    	}
    	return SUCCESS;	
    }
    God that is complicated though.

  4. #4
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Yes, but that's life when you use C

  5. #5
    Registered User
    Join Date
    Aug 2007
    Posts
    81
    Yes

    I hate C but I gotta use it in my C programming course lol

  6. #6
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    You could study C++ sometimes, too. References would sidestep this "complicatedness"
    But, I guess you should concentrate on C for now...

  7. #7
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by keira View Post
    Thanks Elysia, I was able to figure out that it's really:

    Code:
    FILE* inFile = 0;
            openNextFile(&inFile, argv[fileIndex], &fileIndex, argc);
    
    
    /* definition */
    int openNextFile(FILE** inFile, char* fileName, int* fileIndex) {
    	*inFile = fopen(fileName, "rb");
    	(*fileIndex)++;
    	if ( NULL == inFile ) {
    		return FAILED;
    	}
    	return SUCCESS;	
    }
    God that is complicated though.
    It's not THAT complicated.

    But you probably want to do this line instead of what you've got:
    Code:
    	if ( NULL == *inFile ) {
    As it's very unlikely you would get that far if the address of your original infile is NULL.

    Another option is of course to just return infile, instead of passing it as an argument - you just have to compare against NULL instead of FAILED.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  8. #8
    Registered User
    Join Date
    Aug 2007
    Posts
    81
    Ah yeah I forgot to make that adjustment... thanks for the catch!

    if ( NULL == *inFile )

    But when I say complicated, I mean its no wonder C is such an error-prone language. We'll be seeing common vulnerabilities reappearing for years to come while we continue to use such a primitive programming language.

  9. #9
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    LOL, well put. There are so many using C I see around here while there exists such a better language like C++

  10. #10
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by Elysia View Post
    LOL, well put. There are so many using C I see around here while there exists such a better language like C++
    But C++ is only better in the sense that there are for example STL and similar libraries with "already proven and functioning code", not because C++ in itself is "better" at avoiding problems with buffer overflows for example.

    Code:
       char str[100];
       cin >> str;
    will still overflow the 100 bytes if someone enteres more than 100 chars.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  11. #11
    Registered User
    Join Date
    Aug 2007
    Posts
    81
    Yeah Elysia, C++ is definitely not a good example. I was thinking type-safe languages which I predict are the future... The only problem is embedded development will still give C it's life support and hence vulnerabilties will be around yet another 20 years from when they leave the desktop.

  12. #12
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Quote Originally Posted by matsp View Post
    But C++ is only better in the sense that there are for example STL and similar libraries with "already proven and functioning code", not because C++ in itself is "better" at avoiding problems with buffer overflows for example.

    Code:
       char str[100];
       cin >> str;
    will still overflow the 100 bytes if someone enteres more than 100 chars.

    --
    Mats
    If you know how to do it, it's no problem. The only problem is those pesky strings. They should be deprecated, since they aren't safe.
    C++ is also better at type-safety than C, which allows some really stupid things.
    But yes, it could be better.

    Quote Originally Posted by keira View Post
    Yeah Elysia, C++ is definitely not a good example. I was thinking type-safe languages which I predict are the future... The only problem is embedded development will still give C it's life support and hence vulnerabilties will be around yet another 20 years from when they leave the desktop.
    C++ is typesafe. A buffer overflow-safe library for C++ is being developed (or have been?) and has already been adopted my MSVC.
    It's crappy C that's causing problems.
    There are no good modern, safe, better languages IMO. C# is crap (again, IMO), and besides that, what new languages are there?

    But what's bigger is that there are all those C-users out there and crappy teachers who teach them unsafe and poor code.

    Anyway, I believe C++ is a good, typesafe language and I don't believe it's going anywhere (although C should be deprecated IMO).

  13. #13
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Elysia,

    In C++, all the enforcement of such "safe" libraries is dependant on the author of the libraries. In some other languages, the correctness of the code is actually enforced by the runtime environment itself - this means that you CAN'T write code that goes over the edge of a buffer [or at least, you can't do so without jumping through hoops].

    Unfortunately, it also means that EVERY access to an array index takes about three times longer than it does in C - whcih can make a big difference in some pieces of code.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  14. #14
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Quote Originally Posted by matsp View Post
    Elysia,

    In C++, all the enforcement of such "safe" libraries is dependant on the author of the libraries.
    But they DO exist and that's the main point. In the future, maybe someone wants to really do a proper standard and require such safe libraries to be used.

    In some other languages, the correctness of the code is actually enforced by the runtime environment itself - this means that you CAN'T write code that goes over the edge of a buffer [or at least, you can't do so without jumping through hoops].

    Unfortunately, it also means that EVERY access to an array index takes about three times longer than it does in C - whcih can make a big difference in some pieces of code.

    --
    Mats
    *cough* VB, .NET *cough*
    Languages that are really crappy in my book (but my book does in no means reflect the real world). Which is another why C++ should be a good language. We need safer functions, safer libraries and stop messing around with old C-style functions which are (usually) so incredibly unsafe.

  15. #15
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Safe libraries is fine, but what about the code that isn't in the libraries. How do you make THAT code safe?

    Surely you don't mean to say that all applications can only be produced by calling functions in safe libraries?

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Alice....
    By Lurker in forum A Brief History of Cprogramming.com
    Replies: 16
    Last Post: 06-20-2005, 02:51 PM
  2. Debugging question
    By o_0 in forum C Programming
    Replies: 9
    Last Post: 10-10-2004, 05:51 PM
  3. Question about pointers #2
    By maxhavoc in forum C++ Programming
    Replies: 28
    Last Post: 06-21-2004, 12:52 PM
  4. Question...
    By TechWins in forum A Brief History of Cprogramming.com
    Replies: 16
    Last Post: 07-28-2003, 09:47 PM
  5. Question, question!
    By oskilian in forum A Brief History of Cprogramming.com
    Replies: 5
    Last Post: 12-24-2001, 01:47 AM