Thread: FILE pointer as arguement?

Originally Posted by @nthony

the third fscanf argument (a list of pointers) can be ommitted

No actually you can't. You're thinking of *printf. Well...you can omit the list of arguments, assuming all of your scan codes are actually set to skip conversion. Yours aren't.

Originally Posted by @nthony

Also, for thoroughness, I've tried both fscanf and fgets, both resulting in the same error...

Which is?


Quzah.

Originally Posted by MDofRockyView

It depends, for example I don't think that Microsoft wants to write error free code, they want the product to break down after a certain amount of time, so that they can sell you more junk. Another thing is that I agree to test the function call, but I think that the input value can be tested at the appropriate place in the program.

I honestly think its more a question of rushing that purposely creating bugs. The software engineers are fairly competent, however they are human as well. We all make mistakes and sometimes they can get lost in thousands of lines of code. Some errors are VERY VERY hard to find, and much less fix. If you've written a program with others you should know... rarely do their styles fully complement each other.

Also, in fscanf, its true the variables are "optional" but thats kinda like using scanf without the optionals there right? Is there any particular reason to be so imprecise?

Originally Posted by MDofRockyView

It depends, for example I don't think that Microsoft wants to write error free code, they want the product to break down after a certain amount of time, so that they can sell you more junk. Another thing is that I agree to test the function call, but I think that the input value can be tested at the appropriate place in the program.

I don't use Microsoft as my poster child of how to write good code. Don't be lazy and write sloppy code that'll only work in the most stringent of conditions. Yes, you know how your code works, what format the data should be in an how to pass that data for it to work. But will a future user? Chances are, no - users are stupid, and do odd stuff. And when they pass data that isn't up to what you thought it would be - would you rather have accounted for it, and have your program handle it gracefully, even if "gracefully" was an error message informing the user of what went wrong? Or would you rather it core dump / seg fault in his face, causing him to curse at the software you wrote? It's your code; but will it be sloppy or bullet-proof? Sure, you can't predict or handle every problem, but you can cover the minimum of issues.

Never forget the fifth commandment: "Thou shalt check the array bounds of all strings (indeed, all arrays), for surely where thou typest 'foo' someone someday shall type 'supercalifragilisticexpialidocious'."

Originally Posted by MDofRockyView

It depends, for example I don't think

Well you've already proven that...


Quzah.