No, they don't. But in C, you can bet that a lot of them mean that. Which is quite annoying, really. Things that cause undefined behavior should be errors.
No, they don't. But in C, you can bet that a lot of them mean that. Which is quite annoying, really. Things that cause undefined behavior should be errors.
Originally Posted by Adak
Is this particular case undefined behaviour though? I don't see that it is, the way the compiler deals with it seems logical, to me at least ( but I don't think that will count for anything ). Implicit type coercion happens all the time when dealing with void pointers, are we to say that all operations on void pointers will produce undefined behaviour?
In a way, yes but obviously you wouldn't be performing these operations with void pointersBtw, not all warnings mean 'undefined behaviour'.
This is what OP is doing exactly(idea).
Except it has(should has?) defined behaviour?
Code:void *p = NULL; p = &p; if( p == *(void**)p ) { printf("WOW\n"); }
Operations on void* pointers are undefined behavior. You must convert them to a proper type before doing any operations to them.
And the fact that you are converting a pointer to a non-pointer by storing a pointer to pointer in a pointer also causes undefined behavior.
Fine example: On x64 Windows, sizeof(int) = 4, sizeof(int*) = 8. Hence, you truncate the address when converted to an int. Therefore undefined behavior.
Looking at the C standard:
Consequently, it seems that this line might not result in undefined behaviour, but it also might:
Code:int *numPtr =(&numPtr);The above list of constraints is exhaustive, so it is clear that this results in undefined behaviour:
Assuming that converting from void* to void** leads to a correctly aligned pointer, Bayint Naung's example looks well defined, since void* is compatible with void*.Code:if(numPtr == *numPtr)
Look up a C++ Reference and learn How To Ask Questions The Smart Way
Thanks for clearing that up laserlight. I've never read the standard before, I've been told it isn't a fun experience...
