Any idea what this means? Not sure of the language.
(void *) 0x00
A:
looks like C, and it means the pointer to memory location 0. ("void *" means a pointer to raw memory and is a note to the compiler/programmer that the type is unknown or unspecified)
clarification: It is a pointer containing the value 0, which on most platforms is a special value known as NULL indicating an invalid/uninitialized pointer, and dereferencing it causes an exception. On some platforms (some microcontrollers for instance) memory location 0 is a valid pointer value.
Jason S
2009-12-16 16:17:36
It dos NOT mean a pointer to memory location 0 - it means anull pointer. The two are not the same.
anon
2009-12-16 16:20:24
Downvoters: I said exactly what I meant. It means a pointer to location 0. On some platforms this is valid. On most platforms this is a null pointer. The C language does not specify.
Jason S
2009-12-16 16:21:58
The C++ language certainly does - it says such a pointer cannot be dereferenced without invoking undefined behaviour.
anon
2009-12-16 16:23:27
@Jason S: You said exactly what you meant, and it was wrong. The C standard (and C++ standard) do specify what this means, and it isn't what you said. It is the null pointer, whatever representation that may be. If you want to have a pointer to memory location 0, try something like `(void *)(x - x)`. It isn't guaranteed to work, but it isn't guaranteed to produce a null pointer.
David Thornley
2009-12-16 16:25:58
?! how can (void *)(x-x) produce a value that is different from (void *)0 ?
Jason S
2009-12-16 16:26:55
Because 0 is special.
anon
2009-12-16 16:30:59
@Jason S: To expand on Neil's answer, because the standards say one thing about a 0 (or 0x00), and nothing about non-constant expressions. It's an arbitrary thing in the standards.
David Thornley
2009-12-16 16:34:23
Could one of you language gurus please point me to the part of the spec that says that a pointer value is something different than an address (whether physical or virtual address)? My understanding is that the address 0 is taken by convention to mean a null pointer, and if you're creating a microcontroller or microprocessor that runs C code, you don't want to put anything meaningful at address 0, because that's used to indicate a null pointer. But if there were something at address 0, where does it say that a C compiler should do something magically different when dereferencing?
Jason S
2009-12-16 16:35:41
AFAIK, it doesn't say anything about the compiler doing something magically different when dereferencing the null pointer. It just says that it's undefined behavior, which means the compiler is free to do anything (cue demons out your nose quote here). In most cases it will simply treat it as a pointer to location 0, which will usually cause some kind of access violation. The point isn't what we know or suspect it does, it's that it's UNDEFINED what it does, and thus wrong to expect it to do what you want.
rmeador
2009-12-16 16:53:44
6.3.2.3-3: "An integer constant expression with the value 0, or such an expression cast to type `void *`, is called a null pointer constant.55) If a null pointer constant is converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal to a pointer to any object or function."
John Bode
2009-12-16 18:18:52
@Jason S: You seem confused about the difference between a pointer given the value 0, and a pointer with all bits 0. In the program, you designate a null pointer by assigning 0 to it. In execution, the null pointer value may be anything, but it's usually all bits 0. (Arguably, specifying something like Pascal's `nil` or C++0x's `nullptr` would have saved a lot of confusion.)
David Thornley
2009-12-16 20:11:34
@John B: thx for the standard quote. @David: Not confused, just surprised... I knew that 0 was NULL by convention. Didn't know that the C standard was written in such a way as to allow the use of nonzero null pointers, or that assignment of 0 to a pointer could produce a nonzero stored value (do they actually call that out explicitly, or is that just an implied fact / side-effect of the C standard being left open?) I was under the impression that compilers just weren't supposed to locate any user-designated variables at address 0. sigh. I live in the embedded world, far from language lawyers.
Jason S
2009-12-16 21:03:35
(wait, does that mean you're always supposed to do "if (p == NULL)" instead of "if (!p)" ? )
Jason S
2009-12-16 21:04:50
If p is a null pointer, `!p` will always evaluate to true, regardless of the bit pattern used by the platform to represent a null pointer. From the perspective of the *source code*, a null pointer is always represented by 0. It's up to the implementation to map `!p` to `!= actual null pointer value` if the actual null pointer value is not all bits 0.
John Bode
2009-12-16 22:18:41
OK, so it's consistent to support the use of the (!p) paradigm. I guess the take-away from all this I get, is that as a programmer you're not supposed to read/analyze/modify the actual numerical value of a pointer variable, aside from the primitive operations (*p, !p, equality, and pointer arithmetic) which are all automagically performed to Just Work the way they're specified in the standard.
Jason S
2009-12-16 22:38:45
(e.g. semantics performed as if the pointer value actually contained an address... which it may not... although it probably will... but if it didn't you shouldn't count on it.)
Jason S
2009-12-16 22:41:21
@Jason, exactly. On x86 DOS large model, NULL was binary 0, which was in turn a valid pointer that points to the interrupt vector table. Writing to NULL was quite strongly undefined behavior.
Joshua
2009-12-17 16:59:08
+7
A:
In C, it means a NULL pointer, i.e., a pointer that points to no relevant data.
Trying to access this data raises a Segmentation Fault, at least on Unix/Linux.
mouviciel
2009-12-16 16:18:33
well... technically on a microcontroller, address 0 could contain relevant data (though usually doesn't, by convention)
Jason S
2009-12-16 16:19:36
...and a Segmentation Fault is also platform specific, not necessarily the case in all environments.
Jason S
2009-12-16 16:20:35
@Jason: The PS1 contained 3 at address 0. If you saw a weird 3 after a crash the likelihood was you'd probably de-referenced a NULL pointer :D
Goz
2009-12-16 16:22:31
It's from a tattoo that I saw on someone's neck. Some sort of nihilistic commentary, I guess. Thanks.
Todd Holmberg
2009-12-16 16:24:12
Mo accurately, dereferencing the null pointer leads to undefined behaviour. This includes seg faults, but also anything else.
anon
2009-12-16 16:25:25
@Jason: `(void *) 0` does not necessarily point to address 0. Using `0` (or `0x00`) in pointer context produces a null pointer. The physical address that coressponds to a null pointer is implementation-defined. It could be `0xFFFFAAAA` for example. If on some microcontroller address 0 is accessible and usable, then the compilers on this platform should translate `(void *) 0` into some other physical address.
AndreyT
2009-12-16 18:06:32
(you mean if the compiler is an ANSI C compliant compiler. Most of the microcontroller compilers I have seen are ANSI C with exceptions to handle things like interrupts + whatnot... if we're lucky, the compiler manufacturer documents non-ANSI behavior.)
Jason S
2009-12-16 18:38:56
Many embedded controllers have a jump instruction at 0x0, so it can be a valid address. Most of the time, though, the value is used to signify an pointer to nothing.
Thomas Matthews
2009-12-16 20:52:18
A:
Weird C notation. If I had to guess I'd say this guy is trying to force a binary 0 into a pointer on some platform where NULL is not binary 0.
Joshua
2009-12-16 16:18:59
NULL is guaranteed to be 0 according to the ANSI standard.. (this is a very popular misconception that NULL may not be zero)
Earlz
2009-12-16 16:20:09
The null pointer *constant* is guaranteed to be 0 (i.e., a 0 in a pointer context is always interpreted to be the null pointer, and the NULL macro should expand to 0 or `(void *)` 0). The null pointer *value* (the bit pattern used by the underlying platform to represent "nowhere") may or may not be all bits 0. The implementation handles the mapping of the null pointer *constant* (0) to the null pointer *value* (maybe 0, maybe something else).
John Bode
2009-12-16 18:10:32
@earlz: it is a popular misconception that all compilers follow the ANSI standard :) (although it is reasonable to assume that they do, and then go shoot the compiler team who did the violation) :)
Ether
2009-12-16 20:31:34
Going from another comment elsewhere, if the null pointer *constant* is anything other than 0, then expressions like `!p` would not behave uniformly across platforms. If a compiler doesn't conform to that, then it's either *very* broken or *very* tightly coupled to a particular architecture.
John Bode
2009-12-16 22:24:41
+1
A:
The cast suggests C or C++. That's an integer zero cast to a pointer type, which means it's the null pointer. It's a standard way to define the null pointer in C (except that (void *)0 is more commonly used), but in C++ it's a null pointer value of a particular type.
David Thornley
2009-12-16 16:19:42
IIRC, in C++ it is wrong for the null pointer to be typed (i.e. cast to void). I believe it causes some compilation errors if you try. This suggests the OP's language is C.
rmeador
2009-12-16 16:50:23
In C, I like to use `NULL` for the null pointer constant; or if I'm not including any of the standard headers which define NULL, a plain `0` serves me well (I'd rather use `0` than `#include <stddef.h>` just for the `NULL`).
pmg
2009-12-16 19:21:15
@rmeador: In C and C++, `(void *)0` is a null pointer, of type `void *`. In C, this is a useful void pointer, since something of type `void *` can be freely used with any data pointer type, the conversions being automatic. In C++, with its stricter typing, this doesn't work, and the conversion must be explicit. In C, `int * ptr = (void *)0;` is legal, as is `int * ptr = 0;`, both meaning the same thing. In C++, only the second is legal.
David Thornley
2009-12-16 20:04:25