Warning when building!

This is a discussion on Warning when building! within the C Programming forums, part of the General Programming Boards category; I get a warning when building my app and I wonder: Does a build warning always means that something is ...

  1. #1
    Registered User
    Join Date
    Feb 2003
    Posts
    63

    Cool Warning when building!

    I get a warning when building my app and I wonder:

    Does a build warning always means that something is wrong and MUST be redone? The reason I ask is because my app always get 1 warning when building but runs exactly as it should (as far as I know)?

    Maybe a dumb question...
    You cantīt teach an old dog new tricks.

  2. #2
    Registered User Azuth's Avatar
    Join Date
    Feb 2002
    Posts
    236
    Usually, Error's must be fixed, warning's will not stop you compiling, but you should look closely at the warning, they're generally there for a reason, you can usually write the code a bit better and eliminate the warning (but not always, sometimes you just have to have something your compiler doesn't like).
    Demonographic rhinology is not the only possible outcome, but why take the chance

  3. #3
    Programming Sex-God Polymorphic OOP's Avatar
    Join Date
    Nov 2002
    Posts
    1,078
    In most cases you should NOT ignore a warning and times that you are getting a warning yet the program still works, usually means that you didn't do something explicitly so the compiler does it for you (such as implicit conversions between datatypes where data will be lost or not explicitly returning 0,etc.). If that's the case then don't ignore the warning, just explicitly write what you want to do (it will make your code more clear, anyways)! Certain warnings you can ignore such as an identifier's name being too long to store with debug information, but other than things like that, "fix" your code!

  4. #4
    Registered User
    Join Date
    Feb 2003
    Posts
    63
    Originally posted by Polymorphic OOP
    In most cases you should NOT ignore a warning and times that you are getting a warning yet the program still works, usually means that you didn't do something explicitly so the compiler does it for you (such as implicit conversions between datatypes where data will be lost or not explicitly returning 0,etc.). If that's the case then don't ignore the warning, just explicitly write what you want to do (it will make your code more clear, anyways)! Certain warnings you can ignore such as an identifier's name being too long to store with debug information, but other than things like that, "fix" your code!
    Ok, what do you say about my warning:

    warning: assignment makes integer from pointer without a cast

    * (int *) thru_ptr = map[PartIndex]+4;

    The code is running as it should but I don't like the warning every time I build.
    You cantīt teach an old dog new tricks.

  5. #5
    Programming Sex-God Polymorphic OOP's Avatar
    Join Date
    Nov 2002
    Posts
    1,078
    It sounds as though you made map an array of pointers rather than an array of integers. If that is really what you want, then you'll have to explicitly convert:

    * (int *) thru_ptr = (int)(map[PartIndex]+4 );

    If not, it might just be your compiler acting funny. Post the declaration for map.

  6. #6
    Registered User
    Join Date
    Feb 2003
    Posts
    63
    Originally posted by Polymorphic OOP
    It sounds as though you made map an array of pointers rather than an array of integers. If that is really what you want, then you'll have to explicitly convert:

    * (int *) thru_ptr = (int)(map[PartIndex]+4 );

    If not, it might just be your compiler acting funny. Post the declaration for map.
    unsigned char **map = NULL;
    You cantīt teach an old dog new tricks.

  7. #7
    Programming Sex-God Polymorphic OOP's Avatar
    Join Date
    Nov 2002
    Posts
    1,078
    yup, that was the problem!

    map[someint]

    will give you a pointer to an unsigned char, NOT an integer. The fix I posted will get rid of the warning, but i guarantee that your logic is flawed on what you are doing. Your compiler was right in giving you that warning -- the statement doesn't make any logical sense. Rethink what you are trying to do.

  8. #8
    Registered User
    Join Date
    Feb 2003
    Posts
    63
    Originally posted by Polymorphic OOP
    yup, that was the problem!

    map[someint]

    will give you a pointer to an unsigned char, NOT an integer. The fix I posted will get rid of the warning, but i guarantee that your logic is flawed on what you are doing. Your compiler was right in giving you that warning -- the statement doesn't make any logical sense. Rethink what you are trying to do.
    I have tried the line you posted now and it does not give me any warning, nice :-)

    And even better, my app still does exactly the same thing.

    But I don't understand what you mean by:
    Rethink what you are trying to do. Do you mean that I am still doing the wrong thing even after I have used your fix? Can you please explain? Maybe it's just that my mother language is not English ;-)
    You cantīt teach an old dog new tricks.

  9. #9
    Programming Sex-God Polymorphic OOP's Avatar
    Join Date
    Nov 2002
    Posts
    1,078
    Because right now you are storing the memory location of a variable to an integer, which you should pretty much never have to do. You most-likely want map's declaration to be

    unsigned char* map = NULL;

    instead. Post how you are using it to be certain. Don't use my fix simply because it gets rid of the warning. You have problems in your logic in the program.

  10. #10
    Registered User
    Join Date
    Feb 2003
    Posts
    63
    Originally posted by Polymorphic OOP
    Because right now you are storing the memory location of a variable to an integer, which you should pretty much never have to do. You most-likely want map's declaration to be

    unsigned char* map = NULL;

    instead. Post how you are using it to be certain. Don't use my fix simply because it gets rid of the warning. You have problems in your logic in the program.
    Ok, I will try to explain how I use it:

    My app is a MIDI sequencer made for Mac OS X and CoreMIDI.

    At startup my app allocates a memory area to store 1024 pointers like this:

    // allocate space for 1024 pointers, 32 bit * 1024 = 4096 bytes
    if((map = malloc(sizeof(*map) * 1024)) == NULL)
    {
    printf("malloc map failed\n");
    return 1;
    }

    Every time I press the record button my app allocates a memory area (a part). Everything that I play on my keyboard is stored in that memory area, but:

    The first 32 bits of that memory area (the line you helped me with) is a pointer that is used to remember the current position when playing back my MIDI events (every part have a pointer). It works like this:

    The pointer points to the first byte after the pointer itself. It's just a nice way of storing my pointer that way. And the timestamp values (64 bit) and MIDI values (8 bit) is stored after that. And I terminate my recording with 0xFFFFFFFFFFFFFFFF. Why you might wonder, because 0xFFFFFFFFFFFFFFFF is a easy way to stop the pointer to move any futher.

    Feel free to ask if you don't understand what I am trying to explain.
    You cantīt teach an old dog new tricks.

  11. #11
    Programming Sex-God Polymorphic OOP's Avatar
    Join Date
    Nov 2002
    Posts
    1,078
    In that case, you should be doing this:

    unsigned char* thru_ptr;

    thru_ptr = map+PartIndex+1;

  12. #12
    Registered User
    Join Date
    Feb 2003
    Posts
    63
    Originally posted by Polymorphic OOP
    In that case, you should be doing this:

    unsigned char* thru_ptr;

    thru_ptr = map+PartIndex+1;
    That gave me a warning:

    warning: assignment makes integer from pointer without a cast
    You cantīt teach an old dog new tricks.

  13. #13
    Registered User
    Join Date
    Feb 2003
    Posts
    63
    Originally posted by electrolove
    That gave me a warning:

    warning: assignment makes integer from pointer without a cast
    I got 2 errors and 6 warnings as a result of that, heh
    You cantīt teach an old dog new tricks.

  14. #14
    Programming Sex-God Polymorphic OOP's Avatar
    Join Date
    Nov 2002
    Posts
    1,078
    yup, my mistake, sorry about that. It's too late at night here, heh

    unsigned char* thru_ptr;

    thru_ptr = map[PartIndex]+1;

    Why were you adding 4!? that would put you four pointers ahead, not 1 pointer ahead. Pointer arithmetic goes by the size of the type being pointed to. Using + 1 will move you sizeof( unsigned char* ) bytes ahead, which will usually be 4 bytes. If you add 4 like your example, you'd actually be adding 4 * sizeof( unsigned char* ) bytes, whihc would usually be 16 bytes.

  15. #15
    Registered User
    Join Date
    Feb 2003
    Posts
    63
    Originally posted by Polymorphic OOP
    yup, my mistake, sorry about that. It's too late at night here, heh

    unsigned char* thru_ptr;

    thru_ptr = map[PartIndex]+1;

    Why were you adding 4!? that would put you four pointers ahead, not 1 pointer ahead. Pointer arithmetic goes by the size of the type being pointed to. Using + 1 will move you sizeof( unsigned char* ) bytes ahead, which will usually be 4 bytes. If you add 4 like your example, you'd actually be adding 4 * sizeof( unsigned char* ) bytes, whihc would usually be 16 bytes.
    testing testing, hold on...
    You cantīt teach an old dog new tricks.

Page 1 of 2 12 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 10
    Last Post: 07-10-2008, 04:45 PM
  2. Screwy Linker Error - VC2005
    By Tonto in forum C++ Programming
    Replies: 5
    Last Post: 06-19-2007, 03:39 PM
  3. <Gulp>
    By kryptkat in forum Windows Programming
    Replies: 7
    Last Post: 01-14-2006, 01:03 PM
  4. Dikumud
    By maxorator in forum C++ Programming
    Replies: 1
    Last Post: 10-01-2005, 07:39 AM
  5. Interface Question
    By smog890 in forum C Programming
    Replies: 11
    Last Post: 06-03-2002, 06:06 PM

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