Pointers space requirements

Of course it does - what you''re describing is a variable just like any other.

In 32bit systems (Windows/Linux/BeOS PCs and MACs), a pointer is a 4 byte memory address.

A NULL pointer is just a pointer that points to memory address 0.


TheTwistedOne
http://www.angrycake.com

>> A NULL pointer is just a pointer that points to memory address 0. <<

I remember reading somewhere that a NULL pointer on some systems _might_ not be pointing to 0 if it's pointing to NULL, maybe NULL is defined as something else on some systems...?

- Muzzafarath

Mad House Software
The Field Marshals

Edited by - Muzzafarath on July 10, 2000 12:39:48 PM

The point is, it still takes up 4 bytes on a 32-bit system no matter what it''s pointing to... NULL being a different value on other systems has nothing to do with this question!

Thanks people. The 4 bytes thing is what I was looking for. I thought it would be something like that. Thanks again. This helps a lot. And I got an answer without getting flamed for the question, YES!!

Spanky

>> NULL being a different value on other systems has nothing to do with this question! <<

You didn't read my post didn't you? I quoted TheTwistedOne where he said that NULL pointers points to 0. I pointed out that NULL _might_ not be 0 on all systems. Sure it doesn't have anything to do with the original question, but your post didn't have anything to do with the question either (gotcha )! You don't necessarily have to respond to the original question in a reply. Someone else might have asked a new question, or some false information may have popped up and you just have to correct it

- Muzzafarath

Mad House Software
The Field Marshals

Edited by - Muzzafarath on July 10, 2000 3:51:26 PM

You could just have done

sizeof(mypointer);

but there we go.

I''ll tag a little question on the end here, since it''s just cropped up in my mind - it doesn''t matter what type the pointer is does it?

I mean, does an int pointer take up less space than a long double pointer?

And yes, NULL may be different on different systems. Thats part of the idea of pre-defined constants, so you don''t have to go changing your code all the way through when some burocrat changes NULL''s definition. Although, that said I believe NULL would propably be 0, or the classic return test in an if statement wouldn''t work, would it?

You know:

if(!(intp = malloc(sizeof(int))))

Just a few thoughts there.

-Mezz

All pointers, no matter what they point to, take up the same amount of memory, 4 BYTES. Unless you are using 16-bit DOS (why?) then it would be 2 BYTES. Hence the 64k barrier unless you use a DOS extender. But I''m getting off subject so I will stop now.

"Now go away or I shall taunt you a second time"
- Monty Python and the Holy Grail
themGames Productions

quote:

---

Although, that said I believe NULL would propably be 0, or the classic return test in an if statement wouldn't work, would it?

You know: if(!(intp = malloc(sizeof(int))))

---

For maximum portability you should do it like this instead:

if((intp = malloc(sizeof(int))) == NULL)

Since that way works even if NULL isn't 0

- Muzzafarath

Mad House Software
The Field Marshals

Edited by - Muzzafarath on July 10, 2000 3:59:19 PM

Muzzafarath, you have it backwards. The macro NULL will always be 0, however the NULL *pointer* might not be zero. If a compiler comes across code that assignes the value 0 to a pointer, it is required to set that pointer to the null pointer for it''s target system, whatever that address might be.

Hang on, if NULL might not be 0, then

LPVOID pBlockOfMemory = (LPVOID)malloc(sizeof(char)*1024);
if (!pBlockOfMemory)
{
  printf("malloc failed!\n");
  exit(-1);
}
 

isn''t guaranteed to work - yet isn''t that always supposed to work, as long as you''ve got a ANSI C++-compliant compiler?

After all, even if NULL is 0xffffffff (on a 32 bit system, of course), you''re denying the system the use of the top bit of the address space.

Having said that, the MFC debug libraries initialise pointers to 0xcdcdcdcd if you don''t do init them yourself, in an attempt to tell you what the problem is when it falls down.

quote:

---

Original post by mezz
You could just have done

sizeof(mypointer);

---

Unless you change the data packing alignment to something other than 4 bytes... you can do it, and it kills performance, but sometimes it''s necessary (and no, I can''t think /when/ it''s necessary).

TheTwistedOne
http://www.angrycake.com

if (!pBlockOfMemory) {..}
means the following is done:
1. using 4.12-1 that pBlockOfMemory is checked to see if it is the null pointer value and if so ''false'' is the result else ''true''
2. the ''!'' operator is envoked changing ''true'' to ''false'' and ''false'' to ''true''
3. if the result of 2 is ''true'' then the ... is performed
note that NULL has not come into play at all here.

I do not believe that you can define the macro NULL to be a non-zero e.g. 0xFFFFFFFF value. Yes, it is true that the standard plays fast and loose with ''zero'' and ''non-zero'' in that they are not defined anywhere. Reading 18.1-4 and 4.10-1 does not allow for the notation (not the backend code generation) to support a non-zero value. Again, the backend code gen could use a not-all-zero-bit-pattern for an invalid pointer address as this is outside the scope of the standard.

BTW using 0xFFFFFFFF only removes one address not a range of addresses.

zx 495
------------------
From C++ spec (ISO/IEC 14882 Programming Languages - C++):
4.12-1 An rvalue of arith, enum, pointer or pointer to member can be converted to an rvalue of type ''bool''. A zero value, null pointer value or null member pointer value is converted to ''false'' any other value is converted to ''true''

18.1-4 The macro NULL is an implementation-defined C++ null pointer constant in this International Standard (see 180).
Footnote 180: Possible definitions include 0 and 0L, but not (void*)0.

4.10-1 A null pointer constant is an integral constant expression rvalue of integer type that evaluates to zero. A null pointer constant can be converted to a pointer type; the result is the null pointer value of that type and is distinguishable from every other value of pointer or pointer to function type. Two null pointer values of the same type shall compare equal. ...

quote:

---

Original post by zx495

note that NULL has not come into play at all here.

---

Of course it has. Your own quoting of the C++ spec confirms that.
If !pBlockOfMemory is true, then it's a NULL pointer, otherwise it's not a NULL pointer.

If NULL were allowed to be defined as, say, the MFC debug libraries init variables, then you have to explicitly do

if (pBlockOfMemory == NULL) {...}

quote:

---

Original post by zx495

BTW using 0xFFFFFFFF only removes one address not a range of addresses.

---

I didn't say range of addresses, did I? I said 'the top bit', because this one address is variably sized, depending on system architecture/OS - 8, 16, 32, 64.

quote:

---

Original post by zx495

From C++ spec (ISO/IEC 14882 Programming Languages - C++):

---

Reading through again, I see what you mean; NULL is 0, but the NULL pointer might not be.

(Edited to correct a rather embarassing error. I hope nobody saw it)

TheTwistedOne
http://www.angrycake.com


Edited by - TheTwistedOne on July 13, 2000 6:48:18 AM

(Previous contents of this post removed)

Alright, now I'm getting confused - are you saying that if I do

LPVOID pBlockOfMemory = NULL;
printf("pBlockOfMemory = %xh\n", pBlockOfMemory);
 

or

LPVOID pBlockOfMemory = 0;
printf("pBlockOfMemory = %xh\n", pBlockOfMemory);
 

I might not get 'pBlockOfMemory = 0x00000000h' printed out?

Good grief!

TheTwistedOne
http://www.angrycake.com


Edited by - TheTwistedOne on July 13, 2000 7:02:22 AM

Hi,
I was using "NULL" to mean ''the macro NULL'' and "null pointer" to mean the ''null pointer'' in the spec. "NULL pointer" does not really make sense in the way I was using terms.

I misunderstood what you meant by ''top bit'' thinking it meant bit 31 (in a 32 bit address) which cuts down the address space by a factor of two.

I might not get ''pBlockOfMemory = 0x00000000h'' printed out?
Correct. Suppose that we have a system where location 0x00000000 changes, say, a chip select register controlling ram. If the compiler vender used 0x00000000 as the null pointer value at code gen time then the system would be very unstable. This due to the writing of location 0x0000000 by errant programs causing the chip select register to be invalid and ram to become inaccessable. Therefore debugging would be a horrendous chore. So the compiler vendor may choose a different location, say, 0xFFFFFFFF that is a normal ram location where reading/writing does not cause the hardware to operate in a bad way.


Also note that
LPVOID pBlockOfMemory = NULL;
and
LPVOID pBlockOfMemory = 0;
denote the exact same thing (even if NULL is not ''0''). They are just keyboarded differently.

zx495

When writing a portable program to other systems, not only Windows or DOS, then your best bet is to use

if (pointer == NULL)
{
// error
}

instead of

if (!pointer)
{
// error
}

since on other systems NULL might be defined as something other than 0, and since the if statement contains a boolean expression which can only be 1 or 0 (true or false), then any number different than 0 is going to return true... so when doing if (!pointer) you are basically doing

if (pointer != 0)

blah blah..

and if NULL is defined as 0xFF on a certain system

and you use if (!pointer) then if the pointer is NULL it will still execute the code that follows... since there''s a big difference between if (pointer == 0) and if (pointer == 0xFF)...


as far as pointer size goes, in Windows it''s going to be 4bytes, and in DOS it''s going to be 2 bytes.. think about it... a pointer is simply a number variable... and it takes 4 bytes (just like a DWORD does).. in fact, a pointer is a DWORD...which is (unsigned long)...

that''s about i wanted to say.. peace


..-=ViKtOr=-..

The comp.lang.c FAQ has covered this topic in depth. Specificaly: http://www.eskimo.com/~scs/C-faq/q5.4.html,
http://www.eskimo.com/~scs/C-faq/q5.10.html,
http://www.eskimo.com/~scs/C-faq/q5.13.html,
and http://www.eskimo.com/~scs/C-faq/q5.3.html.


In short: The macro NULL will always be 0 (or an expression that evaluates to zero), so the code if (!ptr) will work on all systems. When a compiler sees ptr = NULL or ptr = 0 it will assign ptr the address designated as NULL, which may or may not be 0.