How to set a pointer to NULL



  • Whenever someone claims "there's only one way to do this" in anything related to programming, you can immediately tell that he's lying.

    Of course this also applies to really simple things, such as setting pointer to NULL in C.

    One obvious way to do it is:

    memset(TextureImage,0,sizeof(void *)*1);        // Set The Pointer To NULL

    Original here: http://nehe.gamedev.net/tutorial/texture_mapped_outline_fonts/18001/

    Of course  there are other minor WTF's involved, such as:

    • HDC     hDC=NULL; (earlier in the code)
    • Using pointer array with a single element instead of a pointer
    • The fact that TextureImage[0] is set to another value (which can be NULL, of course) before it's used
    • The comment at the end of the line so clearly reads "Pointer = NULL;"


    [http://www.w3schools.com/tags/tag_a.asp -ShadowMod]


  • Discourse touched me in a no-no place

    @Jupp3 said:

    One obvious way to do it is:

    memset(TextureImage,0,sizeof(void *)*1);        // Set The Pointer To NULL

    Not obvious at all, since it's blatantly wrong. All that does is set the memory to all-bits 0, which isn't the same as setting it to 'NULL' (or zero.). Though since this looks like Windows it's not really going to be that much of a problem.



  •  Sarcasm, dude.

     Though in all seriousness, it's probably an array that's expected to become bigger as one modifies the program. So the real WTF is:

    • Not using the size of the array in the call to memset (either sizeof(TextureImage) or sizeof(void*) * ARRAYSIZE(TextureImage)), macro not included)
    • Not using a #define either for this blatant magic number use
    • Using memset in the first place (see PHJ's post)
    • Not simply initializing the array on declaration with AUX_RGBImageRec *TextureImage[1] = { NULL };
    Edit: Also, use of non-const string pointer in the above function.



  • @PJH said:

    Not obvious at all, since it's blatantly wrong. All that does is set the memory to all-bits 0, which isn't the same as setting it to 'NULL' (or zero.). Though since this looks like Windows it's not really going to be that much of a problem.

    Wrong or not, it doesn't matter. It's assigned another value (which can be real NULL) before it's used for anything else.

     And yes, that was (failed) sarcasm.

     


  • ♿ (Parody)

    @Jupp3 said:

    And yes, that was (failed) sarcasm.

    Seemed clear to me. You can sarcast some of the people all of the time, and you can sarcast all of the people some of the time, but there will always be at least one TDWTFer willing to take you seriously for the sake of pedantic dickweedery.



  • @boomzilla said:

    @Jupp3 said:
    And yes, that was (failed) sarcasm.
    Seemed clear to me. You can sarcast some of the people all of the time, and you can sarcast all of the people some of the time, but there will always be at least one TDWTFer willing to take you seriously for the sake of pedantic dickweedery.

    Then you can't sarcast all the people even once, because there's one person who will take you seriously.


  • I alway prefer:

    Type *p = ......

    // Set to NULL
    p ^= p;

    (post above is tongue in cheek - I am well aware of all of the issues...)



  • @TheCPUWizard said:

    I alway prefer:

    Type *p = ......

    // Set to NULL
    p ^= p;

    (post above is tongue in cheek - I am well aware of all of the issues...)

    Wasn't an "XOR AX" instruction on certain architectures faster than a "MOV 0 AX" instruction?


  • Discourse touched me in a no-no place

    @pkmnfrk said:

    Wasn't an "XOR AX" instruction on certain architectures faster than a "MOV 0 AX" instruction?
    Yes, but if you're dealing with assembler, and you know what all-bits zero means in a pointer context, you don't have anything to worry about.



    It's like the 'swap two variables without a temporary using XOR' "trick" that's perfectly valid in assembler, but not as much so in a cross-platform language such as C.


Log in to reply