0

This is something that's been on my mind for a long time. Every once so often i see people use 1, or -1 as a dummy value for a pointer. To safe the need of a different variable.

Is it okay to use pointers like this? I suppose -1 is okay. But is it also okay to use other negative numbers? And can I be sure 1 isn't a used memory location? And if so, up to which value can i use memory pointers.

P.s. I'm aware storing other data especially positive values in pointers, is very, very bad practice. But I'm just wondering what would be the consequences in any real life situation.

laurisvr
  • 2,724
  • 6
  • 25
  • 44
  • 7
    A pointer should either point to a valid object, or `nullptr` everything else is undefined behavior. – Borgleader May 06 '15 at 17:41
  • 2
    *But I'm just wondering excatly how bad it is* https://xkcd.com/748/ – cnicutar May 06 '15 at 17:43
  • [Related question](http://stackoverflow.com/q/29825352/583833) – Borgleader May 06 '15 at 17:43
  • A well found @Borgleader. I had been searching quite a bit. But did not stumble upon that one. – laurisvr May 06 '15 at 17:44
  • Oh, this seems to also be slightly related. http://stackoverflow.com/questions/3304795/can-a-pointer-address-ever-be-negative – laurisvr May 06 '15 at 17:48
  • @Borgleader I am not sure about that from *basic.compound*: `A valid value of an object pointer type represents either the address of a byte in memory (1.7) or a null pointer (4.10)` wording came from [DR 73](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1367.html#73) – Shafik Yaghmour May 06 '15 at 18:00
  • @Borgleader, "A pointer should either point to a valid object, or nullptr everything else is undefined behavior." Do you have any quote from the standard which states this? – laurisvr May 20 '15 at 08:31
  • @laurisvr No, I took that from chat after having discussed the topic of the related question in my earlier comment. – Borgleader May 20 '15 at 12:34

3 Answers3

2

I bet your compiler warns when you do this? That in itself should tell you that it is bad and should be avoided.

Lots of old crusty code has guards against NULL (or nullptr) for values. You place a -1 in there, which turns into an unsigned 0xffffffff address (32-bit land) into that pointer and it will merrily run though all sorts of things you don't want it to run through. Best case is an immediate access violation / seg fault. Worst case is no one notices and things go out of wack 2 months later and you are found as the, well... 'not smart person' who illegally placed a non-pointer value into a pointer and blew things up. Jobs can be lost for mistakes like this.

As an aside, why would 'people' want to use 1 or -1 in a pointer? Drop nullptr, NULL, or whatever your language supports in there and be done with it. Otherwise put a valid pointer in there and call it good.

Michael Dorgan
  • 12,453
  • 3
  • 31
  • 61
  • Well my 2 cent's would be that it's an 'intuitive' thing to do. You flags something with a nullptr, so why not flag something with 1. I'm aware it's a violation and tempers might rise. That's why i covered myself in the p.s.:). – laurisvr May 06 '15 at 17:55
  • I'd worry less about tempers and religious wars than accidental ommisions that lead to crashes. If you absolutely need a stand in value, then create a global pointer called dummy that is set to null, or have it point to something that will cause an assert if it is invoked. – Michael Dorgan May 06 '15 at 18:09
2

The only pointer values you can portably use are pointers to objects that currently exist and null pointers. (I'm ignoring function pointers and member pointers.)

The purpose of the null pointer is to have a pointer value that doesn't point to any object, and that compares unequal to any pointer that does point to an object. The language only provides one such pointer value for each pointer type.

Sometimes it can be convenient to have more than one distinguished pointer value.

You can define such values yourself -- for example:

const some_type* foo = reinterpret_cast<some_type*>(-1);
const some_type* bar = reinterpret_cast<some_type*>(-2);

Strictly speaking, using either value, even without dereferencing it, has undefined behavior. (I know that's the case for C; I think it's also true for C++.) But if you happen to know that those values are distinct from any pointers that point to actual objects, and that comparisons to them behave as expected, then you can get away with it.

There's some precedent for this in the C standard library. <signal.h> defines three macros for signal handler function pointers, SIG_DFL, SIG_ERR, and SIG_IGN. In some implementations these are defined as the constants -1, 0, and 1 cast to the appropriate pointer type. Those definitions are not portable -- but since they're part of the implementation itself, they don't have to be. The only requirement is that they must compare unequal to any pointer to a user-defined function. (In the implementation I'm using, SIG_DFL happens to be a null pointer; that's not required.)

If a library defines such a pointer, feel free to use it. If it fails, it's a bug in the library. If you want to define such a pointer yourself, be careful, and understand that it might not work correctly on all implementations.

An alternative is to define a static object of the appropriate type, and use a pointer to that object:

static some_type foo_obj;
static some_type bar_obj;
const some_type* foo = &foo_obj;
const some_type* bar = &bar_obj;

This is portable and it gives you pointer values that are guaranteed to compare unequal to the null pointer and to any pointers to user-defined objects.

Keith Thompson
  • 254,901
  • 44
  • 429
  • 631
  • It is not clear to me this is the case in C++ see [my comment above](http://stackoverflow.com/questions/30083887/which-dummy-pointer-values-are-okay#comment48281588_30083887) and the DR that the wording came from. – Shafik Yaghmour May 06 '15 at 18:45
1

It depends on your compiler and (mostly) OS -- on most operating systems there are ranges of addresses that can never be valid. So on such an OS, it is safe to use such addresses as 'magic' values for a pointer that will never compare as equal to any valid object. As long as you never dereference them they should be fine -- and even if you do dereference it, the OS may define the behavior (generally throwing a particular signal).

A more portable alternative is to create 'dummy' global objects and use pointers to them as your special tags. No other valid object pointer will ever compare as equal to the dummy object pointer, and the extra overhead for the dummy object is minimal.

Chris Dodd
  • 119,907
  • 13
  • 134
  • 226
  • I agree with this answer. It's nasty to do it, but in most aspects you can treat a pointer like an int and you'd be fine. Doing so would be utterly stupid, but you could do it:). It's the resolution where the problems would arise. – laurisvr May 20 '15 at 08:27