Warning messages compiling C program

This is a discussion on Warning messages compiling C program within the C Programming forums, part of the General Programming Boards category; When compiling a C program i get the following warnings.How do i modify the code to remove these warning messages? ...

  1. #1
    Registered User
    Join Date
    Sep 2010
    Posts
    1

    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

  2. #2
    a_capitalist_story
    Join Date
    Dec 2007
    Posts
    2,651

  3. #3
    C lover
    Join Date
    Oct 2007
    Location
    Virginia
    Posts
    265
    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.

  4. #4
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    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...

  5. #5
    Registered User
    Join Date
    Nov 2008
    Location
    Bay Area, CA
    Posts
    53
    Quote Originally Posted by CommonTater View Post
    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. :/

  6. #6
    msh
    msh is offline
    Novice
    Join Date
    Jul 2009
    Posts
    568
    Quote Originally Posted by Sorin View Post
    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!

    Quote Originally Posted by puth View Post
    When compiling a C program i get the following warnings.How do i modify the code to remove these warning messages?
    What code?

  7. #7
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Quote Originally Posted by Sorin View Post
    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.

  8. #8
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,047
    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: Toughest bug/war stories

    (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.
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

  9. #9
    Registered User
    Join Date
    Nov 2008
    Location
    Bay Area, CA
    Posts
    53
    Quote Originally Posted by CommonTater View Post
    Half an hour?
    Well that was a long time for me . 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.

  10. #10
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Quote Originally Posted by Sorin View Post
    Well that was a long time for me . 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

  11. #11
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,768
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  12. #12
    Registered User
    Join Date
    May 2009
    Posts
    2,674
    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.

  13. #13
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    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.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. c program that accepts and executes commands?
    By Cimposter in forum C Programming
    Replies: 3
    Last Post: 09-30-2009, 02:58 PM
  2. File Server Help
    By lautarox in forum C Programming
    Replies: 146
    Last Post: 09-24-2008, 06:32 PM
  3. Using malloc
    By ulillillia in forum C Programming
    Replies: 34
    Last Post: 02-20-2008, 05:41 PM
  4. <Gulp>
    By kryptkat in forum Windows Programming
    Replies: 7
    Last Post: 01-14-2006, 12:03 PM
  5. Warnings, warnings, warnings?
    By spentdome in forum C Programming
    Replies: 25
    Last Post: 05-27-2002, 06:49 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21