Warning messages compiling C program

When compiling a C program i get the following warnings.How do i modify the code to remove these warning messages?

1) "test.c", line 614: warning #4212-D: mismatch between character pointer
types "unsigned char *" and "char *"
p_data = m_lines[p_text_idx];

p_data is defined as char *p_data_text = NULL;
m_lines is defined as static unsigned char **m_lines;


2) "test.c", line 919: warning #2513-D: a value of type "int" cannot be
assigned to an entity of type "char *"
if ((cp = strrchr(p_file_path, '/')) == NULL)
^

where char *cp = NULL;
and char p_file_path[MAXPATHLEN];


3) "test.c", line 1033: warning #4212-D: mismatch between character pointer
types "unsigned char *" and "char *"
p_result = m_nls_lines[p_nls_idx] + p_len;

where char *p_result = not_found; and static unsigned char **m_nls_lines = NULL;

Thanks,
Puth

Another crossposter

I think that if you don't know how pointers work, you shouldn't use them. That is, especially in a 1000+ line program like this one. You could just write obtuse code that passes values all over. Not that thats any better.

Actually those warnings are very descriptive... did you try looking at the source lines in question and figuring out what you did wrong?

One thing I do know from experience is that once you solve a problem on your own, you're not likely to repeat it...

Quote:

---

Originally Posted by CommonTater

Actually those warnings are very descriptive... did you try looking at the source lines in question and figuring out what you did wrong?

One thing I do know from experience is that once you solve a problem on your own, you're not likely to repeat it...

---

I once put a \n after the %d in my scanf in a pretty simple program in my intro C class, which took me a half hour to find (the crash being a run-time error).

Once.

although I'm sure everyone else here has a much more fantastic story. :/

Quote:

---

Originally Posted by Sorin

I once put a \n after the %d in my scanf in a pretty simple program in my intro C class, which took me a half hour to find (the crash being a run-time error).

Once.

although I'm sure everyone else here has a much more fantastic story. :/

---

I've sworn to never use a variable named "j" in for loops. It looks too much like "i", and I once spent way, way too much time trying to figure out why my program was "misbehaving". Nevermore! :mad:

Quote:

---

Originally Posted by puth

When compiling a C program i get the following warnings.How do i modify the code to remove these warning messages?

---

What code? :rolleyes:

Quote:

---

Originally Posted by Sorin

I once put a \n after the %d in my scanf in a pretty simple program in my intro C class, which took me a half hour to find (the crash being a run-time error).

Once.

although I'm sure everyone else here has a much more fantastic story. :/

---

Half an hour?

Years ago when Pascal was still popular I made a bracketing mistake that took me something like 2 weeks to sort out... But then, I'm very patient... and, sadly, I still mess up the bracketing on a semi-regular basis.

I was going to write up a long description of how I fixed an annoying bug, then I thought it sounded familiar, and sure enough: http://cboard.cprogramming.com/tech-...tml#post917415

(The rest of that thread is quite interesting as well. You should read it.)

You know you've been here a while when you have (exactly) 7,800 posts and all of your war stories have already been posted somewhere. :)

Quote:

---

Originally Posted by CommonTater

Half an hour?

---

Well that was a long time for me :p. Especially when the whole program was only 20-30 lines. It was one of my first few programs in my first C class. So everything was still pretty new to me.

I think it's going to be a very long time before anything like the bugs in the thread dwks linked to pop up for me.

Quote:

---

Originally Posted by Sorin

Well that was a long time for me :p. Especially when the whole program was only 20-30 lines. It was one of my first few programs in my first C class. So everything was still pretty new to me.

I think it's going to be a very long time before anything like the bugs in the thread dwks linked to pop up for me.

---

I think we all hope they never pop up. But good for you staying with it. I'm guessing you learned a lot in those few minutes. I always learn the most when doing battle with my own mistakes ;)

I'll share a story with you that I experienced yesterday when programming my AI in my 5-in-a-row app.
It was a fine day. It was night, and er... actually, let's skip that part.
Anyway, I had just found a bug. Basically after putting 4 pieces on the board, the CPU should stop me. But it didn't. It carried on as if everything was right. Not good. So set out to debug why this happened, which turned out not to be so trivial to find. Took me at least 30 minutes.

So the first thing I did was trying to step into the AI function after I placed my 4th piece. Since this was a MiniMax algorithm, I first looked at where the CPU tried placing its first move. I noticed it placed it on a square that would cause it to loose. So I next checked when it recursively called itself, signaling the player's turn. So I set a breakpoint in the loop that would break when the loop had reached the coordinates of the square where the player would put a square to win.
Simple enough. The debugger breaks at the right position. So going through the code, I notice that there is already a board layout stored inside the lookup map that corresponds to the layout I'm trying to evaluate right now. The only problem was that the score for the move was... -1. Since the computer would loose if the square was put there, it should be worth -1000 to make the CPU avoids it like the plague.
Great. So now I knew that incorrect information was being put into the map somehow.

Side note: For those who don't know, basically each move is worth a certain amount of "points". Then the CPU picks the move worth the highest amount of points as its move. I store the different board layouts whose points I have calculated in a map to avoid calculating them again, saving time.

So I would have to find how this incorrect information was stored in the map. But stepping through the code line by line obviously wouldn't work--it would take too long! So I knew there was a routine that transformed the internal state of the board into a bitfield stored in an integer (this integer would then be stored in the map). So I put a breakpoint in that routine.
I waited until my 4th move, and then looked at the resulting bitfield that was generated for that specific board layout.
I took this number, put it in windows calculator, converted it into binary and copied its binary representation along with a visual board layout into notepad and began decoding the binary digits into what board layout it would represent. It wasn't really difficult because the code would use 2 bits per square to store what player, or none, had put a square there.
The only problem was that it didn't match the visual layout. So I gave up after a moment, because I couldn't figure it out. The binary coding didn't match the board layout. Great.

So next I changed the code that converts the internal state of the board into something that could be stored in a map from a bitfield to a string. After making minor modifications, I compiled and ran the code. Everything worked perfectly! Except it was a lot slower and took up more memory. But the point is--it worked. So the problem was with how I converted that internal state into a bitfield. I knew that now.

So this time I go back to the code and try to step through the function, seeing if it correctly modifies the bitfield it returns. And it seems to do, for some bizarre reason. Great.
So I went back into the code, placed a breakpoint again, and stopped when placing my 4th move. This time, I took the integer value (the bitfield) and noted it. I knew that the function would be called when the code needed to save the configuration into the map. So I put a breakpoint at the end of the function with the condition that the integer containing the bitfield's value should be equal to that I just noted down. To the integer representation of the particular board layout I used to test when the bug occurs.

Sure enough, the debugger breaks as it should. This time I put another breakpoint with the condition to break if the 3rd or 4th bit (1-indexed) are set (basically Data & 12). I did this because I knew this was a problem since in the bit field I recorded, these two bits were set incorrectly (because there was no square at that position). Stepping out of the routine, then moving the execution cursor back to the routine, I rerun it.

Sure enough, the debugger breaks as the bits that should not be set are set. So I look at the position in the loop it's currently at (the x and y positions). I make another breakpoint to stop just before it executes the code for that particular square. I re-run the function just as before and it stops before the code is executed.

So I step through it, and at first glance, I can't figure out what's wrong. The code works in such a way that it gets the player who owns the square (1, 2 or none), getting an integer (1 or 2) and then left-shifting this into the right position and ORing it with the bitfield. So I notice that for some reason, the left-shift doesn't work. It should shift 2 left 34 bits. I enter it into the Windows calculator and sure enough, I get the right result.
I even look at the assembly of the code, which seems correct before I finally realize what's wrong.

The variable which stores the data to be ORed is an int! And an int is only 32 bits long. The bitfield is 64 bits long. Of course it didn't work! So I change the temporary variable to be the same type as the bit field, recompile, run, and everything works.
Whew.

I spent about 12 hours/2days figuring out the cause of why adding some simple code stopped the embedded project, I support, from working. Could never confirm the exact cause; but developed a theory that it was stack related. The system had a small stack and I declare a few more stack variables I think one more 256 byte array took it down. I had to go though and make sure all the arrays though out the project was declared static. Once the stack is corrupt very weird things were happening in area not even close to the stuff I had changed.

I am still getting learning experiences like the above because of the small size of the code and memory in the board (about max 512 K each. Having more code decreases storage memory.)

I really have to get the code size controlled/small enough to have room to use the debugger/tracer.

Tim S.

Wow, Elysia... not fun, but well done. Excellent troublshooting skills, there.

stahta .. It's been along time since I did PIC programming but the constraints can be killers. You can do amazing stuff but there's never any room to spare.

My worst nightmare?

Well, I'm very slightly left right dyslexic ... d and b or q and p often look the same to me. So here I am getting wrong answers from this relatively simple app to calculate optimal dipole dimensions (like 50 lines) and it's driving me right up the wall... For the life of me I can't see what's wrong with my code. Fine I sets it aside for a few days, does something else and comes back to it. Just as I'm getting started a friend stops by for coffee, so we're sitting at the computer and I'm explaining why this is ........ing me off. Almost instantly he looks and goes "You spelled 'dime' wrong"... Sure enough I had "bime" instead... But the thing I don't get, to this day, is why it compiled. It should have produced an unknown type error when it got to my silly spelling error.