frwite() writes line twice

Hi again, I'm trying to make a program that converts a bit map into an array and then writes it to a header file so i can include it into a program for the DS. One i know there's a program that does something like this for you but i would rather make one myself,

two I have exhausted all means of trying to get this program TO NOT print two #endif 's in the file. I have a for loop that writes the info my convertfunction gives it then after the for loop it writes the array --
char arr[]="#ifndef FUNCTIONS_H_INCLUDED\n#define FUNCTIONS_H_INCLUDED\nbmparray={\n\0";(i've also tried w/out the \0 just incase)

problem is it writes this before the for loop executes then writes the stuff in the for loop and then writes it again at the end of the file like its supposed to. I am using fwrite() for all my writing parts if any one has some insight it would be helpful!

I'm 99.9999% positive ....
It's out side the for loop and any other loop
There is only one fwrite that writes arr to the file
It writes it flawlessly each time but it writes it twice which just confuses the heck outa me
I just don't know
I am 99.9999% sure of this because i've looked at it when i was well rested,fed and in a good state of mind, i've also re read my code over and over and over for a while now and still have absolutely no idea(it may even be something verry simple i have over looked somehow that i dont know about the fwrite() function which im looking into), again any insight will be appreciated!

 

This is a straightforward task and I've written routines to do this in a number of different languages. I'd be happy to help, but you have to present your problem properly. Here are some guidelines:

Show your full source code, properly indented (don't just paste it into your post, as it will not be properly indented; attaching as a plain text file is better). Remove all ancillary code that isn't related to the problem and give the input data and command line invocation. Show the output that demonstrates the problem. Also, if you don't want to torque off some experienced programmers, do not use tabs for indentation. I've seen software engineers nearly come to blows over tab use (same types of weenies that argue vi vs. emacs ) and the only effective management policy is to leave them out totally.

Give the compiler command used to build if it isn't trivial. Also state the compiler you're using and the computer OS you're building under.

State the language you're programming in. You're likely using C or C++, but don't make the reader guess.

I've read a lot of code in the last 30+ years and I personally won't spend the effort to understand some if it's not attractively displayed and the problem is reduced to the minimum code that demonstrates the problem. For some reason, it takes many people years of programming to learn to do this, maybe because they haven't spent enough time trying to figure out the bugs in other persons' code.

 

Some ideas...
*Have you tried stepping through the code with a debugger? Be sure the string you're feeding fwrite() really is what you think it is.
* Are you opening the file with fopen(..., "w")? Sometimes even us old pros accidently put "r" instead and get chaos. (It shouldn't work at all, not write something twice, but whatever...)
* Exactly why are you using fwrite() and not frprintf()? I can't imagine it really matters, but by toying with alternative coding I sometimes uncover the culprit.
* Possibly, if you've been fwrite()ing or fprintf()ing a lot without any \n or other buffer flushes happening, and you're using a older buggy compiler or C library, there could be a buffer overrun leading to arbitrary chaos. Not likely these days, but i'll never stop begin paranoid about such things. Just to be sure.
* If you can't get rid of the second "#endif", well just write an extra "#if (1)" at the start of the mess, and all will be well. Until the real cause of the duplication is found and fixed, anyway.

 

Hi all, sorry i've been away for a bit. I figured it out it, i had to use strlen() in my the fwrite. i thought i could be lazy and have an integer that was not always going to be the same length of the string i had in my array. Sorry before i didn't have code in a nice easy to read fashion, also i tried using the debugger in code blocks once and got frustrated and since i have never used it maybe i'll take a look into it again.

now the problem is i changed my custom handlein function around a bit to make it more "console" like and at a certain same point in the program it crashes. I get no build errors but im using pointers so i know something's going on, but it only happens in my part of the program that handles with the fileoutput, can some one take a look at my handlein() and tell me if they see anything initially dangerous or wrong with it? It's my own function that takes a pointer of an array you want to modify.
handlein() is meant to be inside a loop and outside a loop for say file name's of a file pointer, i have a text for it all. It also returns a character which is almost always 'c' or 'q' and will be anything else i implement in the future.

View attachment handlein.txt (works flawlessly, have no problems no matter how many times it loops)
now it seems to run fine but in my program i believe it crashes it.
View attachment main.txt ( crashes at the handlefilewrite file function) note i know there's probably other errors in here hence why it doesn't really convert it right to an array in a header file. if you have a .bmp file that is not 4x2 change the settings in the deffinition.

Really i just want to get to the bottom of my handlein() error, im sure i can figure out how to fix the program to read correctly from the file and write correctly to the file on my own time. You don't have to look at main.txt just tell me if you see anything dangerous about my handlein() function. Thank you for any insight.
handlein.txt's code:

 

The fact that you aren't getting build errors tells you almost nothing other than your program is syntactically correct. The run-time errors and crashes you are seeing tell you much more; namely, that your program has semantic errors. Now is the time to learn how your debugger works and use it to find out what variables (especially pointers) have values that are different from what you're expecting.

You don't say what compiler you're using (and therefore which debugger), so I can't offer any advice on debugging. Many debuggers have the ability to view memory (essential when you're dealing with pointers), set breakpoints, single-step through code, and other capabilities.

Can you be more specific about the run-time errors that are produced and exactly where? With this information, one of us on this forum can probably steer you in the right direction.
Mark

 

Hi, Mark i'm using the Mingw compiler. With notpad++ as my editor. I beleive it's a memory access violation judging from a google of the Exception Information of the Error Report Contents of the windows error reporting popup.

the Exception info is as follows:

I am trying to learn how to debug with mingw right now... Other than that it's a normal pop up from windows about error reporting saying x.exe has encourntered a problem and needs to close. We are sorry for the inconvenience. then a Send Error Report or Don't Send.

 

I don't have a clue. I don't see anything obvious in your code that would cause problems. The pointer you're passing in the call to handlein() points to a block of memory allocated on the stack, which is fine. Many times people new to C/C++ pointers neglect to point their pointers to memory, and cause problems when they attempt to write to random memory locations.

I've never heard of mingw or its debugger, so I can't offer you any help there. Since that's the one you're using, look for how to get it to single step through your program and report the values of variables. Hopefully you'll get expert enough in its use to find out which line of code is executing just before the exception is thrown.

 

Thanks Mark, i've been looking into a program called ollydebug. Apparently it completely dissasembles an exe into the single instructions that the processor reads. Would it be wise to take up learning olly debug? Only because on mingw's main website mingw.org on the /wiki/FAQ page under debugging it shows i need to download another program and its only for memory leaks. I really haven't found anything else on their website.

 

I think I remember reading about ollydbg a while back. I don't think it would be very useful to you. It disassembles a program into the machine code instructions that the processor uses, and displays the x86 assembly for your code. To be able to understand this you would have to learn x86 assembly on top of the C that you're learning now. That might be a daunting task, so I would advise against unless this is something you really want to do. What I would do first, though, is read all the documentation available for mingw-gdb, the debugger on your system.

 

Hi,
I can't see where you are setting the array pointer back to the start of the array..

Is the problem a simple overflow & you are writing to memory outside the array limits?