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.

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**.

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.

Yes, but that's life when you use C ;)

Yes :)

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

You could study C++ sometimes, too. References would sidestep this "complicatedness" ;)
But, I guess you should concentrate on C for now...

Quote:

---

Originally Posted by keira

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

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.

LOL, well put. There are so many using C I see around here while there exists such a better language like C++ :D

Quote:

---

Originally Posted by Elysia

LOL, well put. There are so many using C I see around here while there exists such a better language like C++ :D

---

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

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.

Quote:

---

Originally Posted by matsp

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

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).

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

Quote:

---

Originally Posted by matsp

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.

Quote:

---

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.

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