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

Quote:

---

Originally Posted by matsp

Safe libraries is fine, but what about the code that isn't in the libraries. How do you make THAT code safe?[/code]
Lots of vulnerabilities come from improper memory handling, like buffer overruns.

---

And usually this is due to C-style functions. Using C++ objects usually takes care of that little problem for you.
Otherwise you need to properly learn how to handle memory yourself.
I believe that is THE biggest problem in the language.

Quote:

---

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

---

No, of course not. But using safe libraries lessens the risk for programming errors and mistakes and vulnerabilities, so it's a good thing to use them.

There are safe and secure libraries for both C and C++. There are novice programmers in both languages that neglect these libraries. Basing the security of a language on its library support is not the way to go for this reason. Unless there was some way to get rid of all the old insecure libraries so new programmers don't keep using them...

C and C++ are terrible bug prone languages. Although I do prefer to program in C++ rather than in C because I like the STL and private data types.

Quote:

---

Originally Posted by keira

There are safe and secure libraries for both C and C++. There are novice programmers in both languages that neglect these libraries. Basing the security of a language on its library support is not the way to go for this reason. Unless there was some way to get rid of all the old insecure libraries so new programmers don't keep using them...

---

Oh how we'd love that, but seeing as lots still use plain old C, I can't see that happening anytime soon, unfortunately.

Quote:

---

Originally Posted by Elysia

And usually this is due to C-style functions. Using C++ objects usually takes care of that little problem for you.
Otherwise you need to properly learn how to handle memory yourself.
I believe that is THE biggest problem in the language.

---

You don't manage memory in C++?

With smart pointers, string classes, vectors... all that complexity of keeping your arrays intact and all that goes away. No need to worry about it. And that's pretty much the biggest issues with memory.
I can't think of an example in a general program where I have to handle memory myself with a raw array, raw buffer or such (well substitute raw buffer for vector for that purpose).
Now there's where the most of the work goes into, no? To make all that work like it should?

You never use dynamic memory explicitly?

I suggest that we (especially you, Elysia) stop starting "C versus C++" and other language comparison discussions in the middle of threads that have nothing to do with language comparison.

I do, of course. I know how to handle it properly.
But most of the time, I know I can get away with not doing it.