ISO/C 2011, clause 6.3.2.3: ---- An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant. If a null pointer constant is converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal to any object or function. Conversion of a null pointer to another pointer type yields a null pointer of that type. Any two null pointers shall compare equal. ---- int *var1 = 0; int *var2 = (void*)0; result in var1 and var2 to both be null pointers (the null pointer constant being « 0 » or « (void*)0 »). This doesn’t matter if your specific machine encodes null pointers as ‘0xffffffff'. On your specific machine, however: int *var1; int *var2 = 0; memset(var1, 0, sizeof(var1)); won’t make var1 be a null pointer, but var2 will internally contain this 0xffffffff, and will be a null pointer. Cordialement, Erwann Abalea > Le 11 janv. 2017 à 17:18, Jeffrey Walton <noloader@xxxxxxxxx> a écrit : > >> Could someone from the OpenSSL team please explain the rationale for this >> decision? What is the problem with using assignments with 0 or NULL to >> initialize pointers? > > I'm not from the team, so take it for what its worth... > > On some systems, NULL is _not_ 0. NULL can be anywhere in memory the > architecture wants it to be. It can be in a high page in memory, too. > One of my instructors in college was telling me about a system he > worked on where NULL was an address in the last page in memory, so it > took a value like `0xffffffff`. > > Jeff > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
