3

I am exposed to the pointer int* i, of which I only know its memory is allocated but am not sure it has been initialized to some integer or not.

If I try to deference it, what would happen? In other words, how should I check if it is initialized or not? If it is not, I'd like to assign an integer value to that address; otherwise I do nothing.

Terry Li
  • 16,870
  • 30
  • 89
  • 134
  • 2
    If memory is allocated to it, it's initialized but might have random garbage data depending on how the memory was allocated. – wkl Nov 29 '11 at 20:35
  • Possible duplicate: http://stackoverflow.com/questions/1576300/checking-if-a-pointer-is-allocated-memory-or-not – jasso Nov 29 '11 at 21:13
  • 1
    Raymond Chen says [IsBadXxxPtr should really be called CrashProgramRandomly](http://blogs.msdn.com/b/oldnewthing/archive/2006/09/27/773741.aspx) – ephemient Nov 29 '11 at 21:17

5 Answers5

5

Define "initialized". There will always be some value, and there is no way you can tell whether that value is a garbage or an integer, because any 32 bits of garbage will yield some value. You can dereference it though, no problem.

0

I am exposed to the pointer int* i, of which I only know its memory is allocated but am not sure it has been initialized to some integer or not.

If i was allocated as a pointer and not initialized you will get a segment violation. If i was allocated and initialized to some integer X... i.e.

int X = SOMEVALUE;

    int* i;
    i = &X; // It would seem silly to malloc a single int...

Then it is initialized IF and only if X was initialized. If you know some expected bounds for the value it is pointing to then it would be recommended to perform a bounds check before using...

If I try to deference it, what would happen? In other words, how should I check if it is initialized or not? If it is not, I'd like to assign an integer value to that address; otherwise I do nothing.

My typical practice is initialize pointers to 0 or NULL until I have a real value to feed them. Prior to calling an *X*alloc function of somesort... Then if it anywhere I would try to use it... I do a...

if (myPtr == NULL)
{
 printf("Run failure handling code...\r\n");
 return FUNC_FAILED_CONST;
}

But I would have to more info to know your situation....

NoMoreZealots
  • 5,274
  • 7
  • 39
  • 56
0

Good programming practice includes assigning NULL to pointers that are uninitialized. If you're handling a pointer from somewhere else, it is common to check to make sure it isn't NULL. In your case:

if (i != NULL)
  *i = the_int_you_assign;

However, if there is no specified way to handle it and you can't count on good programming practices, then you can't really defend yourself.

dbeer
  • 6,963
  • 3
  • 31
  • 47
0

i is typically a name for an integer (usually int) object. Calling a pointer i is confusing.

So let's assume you have

int *p;

You say "its memory is allocated". Do you mean memory for the pointer object itself (which is allocated when you declare p), or do you mean memory for the int object it points to?

In either case, you can't tell whether it's been initialized or not.

If p has static storage duration, then its initial value (in the absence of an explicit initializer) is a null pointer; it doesn't point to anything. Otherwise, its initial value is garbage, and you cannot safely do anything with it other than assigning some valid value to it.

If, on the other hand, you mean that p has been initialized to point to some int object, but that object may or may not have been initialized, then you have a similar problem. If you have:

int *p;
p = malloc(sizeof *p);
if (p == NULL) {
    /* malloc() failed! */
    exit(EXIT_FAILURE);
}

then p points to an allocated int object, but that object's value is garbage. On most systems, you can safely access the value (*p) -- but there's no point in doing so. But it's possible that int has trap representations; if so, just accessing the value of *p has undefined behavior, and could cause your program to crash. And an optimizing compiler can do unexpected things in the presence of undefined objects; it can assume that it's been initialized to some value, and not bother to actually fetch the stored value.

There is no special value, marker, or flag for an uninitialized int object. It is entirely up to you, the programmer, to ensure that any object has a valid value before you attempt to access it. (Some languages keep track of these things for you; C is not one of those languages. Of course, a lot of the implementations of those languages are written (very carefully) in C.)

So you're asking the wrong question. If you don't know whether an object has been initialized, the solution is to find out (logically, when you write the code, not during program execution) whether it's been initialized. The best way do to this is usually to ensure that it is initialized.

If you're trying to do something like the following pseudo-code:

 if (/* *p has been initialized */) {
     do something with *p;
 }
 else {
     do something else;
 }

then you're doing it wrong. Instead:

/* Ensure p points to a valid int object */
*p = some_value;
/* Now you *know* *p has been initialized */
do something with *p;
Keith Thompson
  • 254,901
  • 44
  • 429
  • 631
0

You can also re-define malloc in such as way that it will allocate memory block and initialize it to zero bytes at once by using such macro:

#define malloc(p, size) do {if (p != NULL) {p=malloc(size); memset(p, 0, size);}} while(0);

Or if you prefer malloc can be re-defined in terms of calloc:

#define malloc(p, elCount , elSize) do {if (p != NULL) {p=calloc(elCount,elSize);}} while(0);

By forcing such construct you will be sure that any programmer which uses malloc() - also initializes memory properly, so that no pointer shows to garbage data.

Agnius Vasiliauskas
  • 10,935
  • 5
  • 50
  • 70
  • And why do you prefer this over `calloc`? – jasso Nov 30 '11 at 01:20
  • I don't. Yes - `malloc()` macro could be written in terms of `calloc`. This was just an example how to override standard malloc function so that if devs are trying to use *old definition of malloc* - they get compile-time errors about different malloc signature and thus are forced to use calloc() or re-defined correct malloc() or if they want to cheat - they can also re-define that macro back to standard (but i'm not counting on this, because in C you have plenty of possibilities to cheat on everything :-( . So there must be some level of agreement to develop in good faith) – Agnius Vasiliauskas Nov 30 '11 at 09:46
  • Sorry I was a bit unclear. What I actually meant that if you want to define malloc as a macro that acts like calloc, is there any preference why use memset in the macro instead of using calloc in the macro? – jasso Nov 30 '11 at 09:56
  • I think there is no such preference and it can be done in both ways. (I've added your suggested way into post), thanks. – Agnius Vasiliauskas Nov 30 '11 at 11:35