locked
NULL vs '\0' RRS feed

  • Question

  • Hello,

    Okay... in structure I declare like this:

     unsigned short* m_pFlshLstItms[5];         

    Then later in code I try to innitiate like this:

    memset(pFdbObj->m_pFlshLstItms, NULL,     ((sizeof(pFdbObj->m_pFlshLstItms))/2));

    and doesn't work????

    I have to do this:

    memset(pFdbObj->m_pFlshLstItms, '\0',     ((sizeof(pFdbObj->m_pFlshLstItms))/2));

    What's the difference if I do '\0' or NULL ????

    Why does the null character '0\' work for the "short*" type and the "NULL" does not?

    r

    Thursday, December 1, 2011 5:01 PM

Answers

  • On 12/1/2011 4:47 PM, roberto wrote:

    MnMap* MNM_newMnMap(unsigned char amtFldrIco)
    {
    unsigned short x[6]; //  assuming amtFldrIco always equals 6!!!!
    int i;

    pMnMapObj->m_pFldrIco = malloc((sizeof(unsigned short)) * amtFldrIco);
    memset(pMnMapObj->m_pFldrIco, 5, (sizeof(unsigned short) * amtFldrIco));

      for(i=0; i<6; i++)
      x[i] = pMnMapObj->m_pFldrIco[x];

    }

    I don't qutie understand what you are trying  to do here, but it looks like you've figured out how memset works. Problem solved?


    Igor Tandetnik

    • Marked as answer by _roberto_ Thursday, December 1, 2011 10:10 PM
    Thursday, December 1, 2011 9:56 PM

All replies

  • On 12/1/2011 12:01 PM, roberto wrote:

    Okay... in structure I declare like this:

      unsigned short* m_pFlshLstItms[5];

    Then later in code I try to innitiate like this:

    memset(pFdbObj->m_pFlshLstItms, NULL,     ((sizeof(pFdbObj->m_pFlshLstItms))/2));

    Why divide by two? What's that supposed to achieve? memset() takes the size in bytes, and sizeof returns the size in bytes.

    and doesn't work????

    Doesn't work in what way? What results do you observe, and how do they differ from your expectations?

    I have to do this:

    memset(pFdbObj->m_pFlshLstItms, '\0',     ((sizeof(pFdbObj->m_pFlshLstItms))/2));

    What's the difference if I do '\0' or NULL ????

    In C, NULL is usually defined as (void*)0 , and is intended to be used with pointers. memset() takes an int as its second parameter: void* is not convertible to int. On the other hand, '\0' is the same as 0 (I think it even has the type of int, not char as it would in C++).

    In C++, NULL is usually defined simply as 0, and so passing it to memset() would work. It's still a bad idea - using NULL this way is likely to confuse anyone reading the code, as NULL is expected to be used with pointers.

    Why does the null character '0\' work for the "short*" type and the "NULL" does not?

    memset() doesn't know about the real type its first parameter is pointing to (note how the type of the parameter is void*). It simply treats it as a pointer to a block of bytes.


    Igor Tandetnik

    • Proposed as answer by Carl Daniel Thursday, December 1, 2011 8:09 PM
    Thursday, December 1, 2011 5:13 PM
  • aaaarrgh! I got confused with another example in my code..... here it is:

    Declared in structure:

    unsigned short* m_pFldrIco;  

    Innitialized in New() function:

    MnMap* MNM_newMnMap(unsigned char amtFldrIco)
    {
    pMnMapObj->m_pFldrIco = malloc((sizeof(unsigned short)) * amtFldrIco); 
    memset(pMnMapObj->m_pFldrIco, 0,  ((sizeof(pMnMapObj->m_pFldrIco))/2) * amtFldrIco);
    //...
    }

    The latter example, I divide by 2 since it is a block of continous memory of shorts that I want to quantify! right? Where as my innitial example the array of pointers are all 4 bytes anyways and are already existing in the array so I wouldn't need to divide by 2 right? Doing this:

    memset(pFdbObj->m_pFlshLstItms, '\0',  sizeof(pFdbObj->m_pFlshLstItms));

    would simply set all the bytes (4bytes/index of the array) to 0... right?

    >memset() takes an int as its second parameter

    Yes! I should be a little more observant!

    >void* is not convertible to int.

    On another note I guess this is what I was trying to do which makes no sence:

    int *p = NULL; 
    int s;
    s = (int)NULL;            OR            s = (int)void*;


    >In C++, NULL is usually defined simply as 0, and so passing it to memset() would work. It's still a bad idea - using NULL this way is likely to >confuse anyone reading the code, as NULL is expected to be used with pointers.

    Understood....

    Thanks Igor.

    r

    Thursday, December 1, 2011 8:17 PM
  • On 12/1/2011 3:17 PM, roberto wrote:

    aaaarrgh! I got confused with another example in my code..... here it is:

    Declared in structure:

    unsigned short* m_pFldrIco;

    Innitialized in New() function:

    MnMap* MNM_newMnMap(unsigned char amtFldrIco)
    {
    pMnMapObj->m_pFldrIco = malloc((sizeof(unsigned short)) * amtFldrIco);
    memset(pMnMapObj->m_pFldrIco, 0,  ((sizeof(pMnMapObj->m_pFldrIco))/2) * amtFldrIco);

    Here sizeof makes even less sense. The size of pointer P, whether divided by two or otherwise, has absolutely nothing to do with the size of the block of memory P points to. You know perfectly well what the real size is - you've just passed it to malloc, after all.

    The latter example, I divide by 2 since it is a block of continous memory of shorts that I want to quantify! right?

    I don't see how the conclusion follows from the premise. Yes, you have allocated an array of shorts - what does this have to do with taking the size of a pointer and dividing it by two?


    Igor Tandetnik

    Thursday, December 1, 2011 8:31 PM
  • ooooffff boy..... why don't I just do this:

    ========================================

    In struct:

    unsigned short* m_pFldrIco;

    Innitialized in New() function:

    MnMap* MNM_newMnMap(unsigned char amtFldrIco)
    {
    unsigned short x[6]; //  assuming amtFldrIco always equals 6!!!!
    int i;

    pMnMapObj->m_pFldrIco = malloc((sizeof(unsigned short)) * amtFldrIco);
    memset(pMnMapObj->m_pFldrIco, 5, (sizeof(unsigned short) * amtFldrIco));   

     for(i=0; i <6; i++)
     x[i] = pMnMapObj->m_pFldrIco[x];

    }
    ===========================================

    Did some tests with memset by assigning "5" as the default value and x was:

    x[0] = 0x0505
    x[1] = 0x0505
    x[2] = 0x0505
    x[3] = 0x0505
    x[4] = 0x0505
    x[5] = 0x0505

    which makes sence ... no?

    I don't really remember why I was dividing by 2....  I don't know why I do:

    unsigned short* m_pFldrIco;

    I could of done:

    unsigned int* m_pFldrIco;

    And wouldn't of made a difference right?

    r

    Thursday, December 1, 2011 9:47 PM
  • On 12/1/2011 4:47 PM, roberto wrote:

    MnMap* MNM_newMnMap(unsigned char amtFldrIco)
    {
    unsigned short x[6]; //  assuming amtFldrIco always equals 6!!!!
    int i;

    pMnMapObj->m_pFldrIco = malloc((sizeof(unsigned short)) * amtFldrIco);
    memset(pMnMapObj->m_pFldrIco, 5, (sizeof(unsigned short) * amtFldrIco));

      for(i=0; i<6; i++)
      x[i] = pMnMapObj->m_pFldrIco[x];

    }

    I don't qutie understand what you are trying  to do here, but it looks like you've figured out how memset works. Problem solved?


    Igor Tandetnik

    • Marked as answer by _roberto_ Thursday, December 1, 2011 10:10 PM
    Thursday, December 1, 2011 9:56 PM
  • okay Igor,

    Thanks

    r

    Thursday, December 1, 2011 10:04 PM
  • >I don't know why I do:
    >unsigned short* m_pFldrIco;
    >I could of done:
    >unsigned int* m_pFldrIco;
    >And wouldn't of made a difference right?

    Difference to what? It will certainly make a difference
    if you do any pointer arithmetic - including increments
    and decrements - with the pointer. The type of the pointer
    tells the compiler by how many bytes it needs to change
    the pointer.

    Assuming Win32 or equivalent:

    unsigned short us = 0;
    unsigned short* m_pFldrIcoUS = &us;
    ++m_pFldrIcoUS; // increments the pointer by 2 bytes

    unsigned int ui = 0;
    unsigned int* m_pFldrIcoUI = &ui;
    ++m_pFldrIcoUI; // increments the pointer by 4 bytes

    I'm sure you already knew that - but neophyte lurkers
    may not.

    - Wayne
    Friday, December 2, 2011 1:59 AM
  • Yes Wayne... I knew this....  Thanks for your concern. Appreciated.

    r

    Friday, December 2, 2011 6:31 PM