Does null pointer in a struct occupy more memory than no pointer at all?

Question

I'm trying to make a small text editor and efficient (space/time wise). I also want to save changes to the text; I would save changes and the main text in two lists, both made of nodes like this:

struct node{
    int startingLine;
    int endingLine;
    char *line;  
    char *newLine;
};

My idea is to use this struct both for the text list and the changes list;line and newLine are to point at char arrays (the lines of text)

when these are text nodes the newLine array is empty or points at null, and when the line gets changed this node is just moved to the changes list and the newLine array gets filled with the new line that replaced the first in the text;

this way I would not have to free the node from the text list and malloc another node in the changes list and also copy all the information; but:

• when I try to set an array to NULL i get an error; I wonder why, I thought array names were just pointers?

• also, to use the heap I only know malloc(sizeof(struct node)), does it allocate space for the second pointer too even if i don't immediately need it?

So in conclusion I ask if this is a good idea or how to work around it or if it can be polished somehow; maybe immediately after allocating a node I should set newLine to NULL? A NULL pointer occupies no memory at all or still something compared to not putting any pointer in the struct? Because as is said the idea would be to have the text list made of nodes but with all their "useless" newLine pointers hanging there.

Answer 1

when I try to set an array to NULL i get an error; I wonder why, I thought array names were just pointers?

No. Unless it is the operand of the sizeof or unary & operators, or is a string literal used to initialize a character array in a declaration, an expression of type "N-element array of T" will be converted ("decay") to an expression of type "pointer to T" and the value of the expression will be the address of the first element of the array. Otherwise, arrays and pointers are completely different animals.

When you declare an array like

int a[10];

what you get in memory is

+---+
|   | a[0]
+---+
|   | a[1]
+---+
 ...
+---+
|   | a[9]
+---+

That's it. There's no separate pointer object storing the address of the first element. There's no a object separate from the array elements themselves. It's just a sequence of elements. During translation, any instance of the expression a that's not an operand of sizeof or unary & will be replaced with the address of a[0].

also, to use the heap I only know malloc(sizeof(struct node)), does it allocate space for the second pointer too even if i don't immediately need it?

It will allocate space for the line and newLine pointer members, yes; it won't allocate any additional memory for them to point to. That would have to be done as a separate step, e.g.

struct node *n = malloc( sizeof *n );
if ( n )
{
  n->line = malloc( line_length + 1 ); // sizeof (char) is 1 by definition so we don't need a sizeof here, +1 to account for string terminator;
  ...
}

This means you'll have to call free( n->line ) before calling free( n ).

A NULL pointer occupies no memory at all or still something compared to not putting any pointer in the struct?

A pointer object takes up the same amount of space regardless of whether its value is NULL or not. It's like an int takes up the same amount of space whether it's value is 0, 1, 65535, or 2147483647.

The exact size of a pointer type depends on the platform and the pointer type itself. C does not require a specific size for pointer types, nor does it require all pointer types to be the same size. The only requirements are

• void * and char * have the same size and alignment;
• pointers to qualified types have the same size and alignment as their unqualified equivalent (i.e., const int * and volatile int * and int * should all have the same size);
• pointers to all struct types have the same size and alignment;
• pointers to all union types have the same size and alignment;

On most modern, general-purpose platforms like x86 and x86-64, all pointer types will have the same size. That may not be the case on some embedded or special-purpose architectures, though.

Answer 2

when I try to set an array to NULL i get an error; I wonder why, I thought array names were just pointers?

No. An array variable is similar to a pointer, and convertible to a pointer, but it's a different type. See Is an array name a pointer? for a more complete answer on this.

also, to use the heap I only know malloc(sizeof(struct node)), does it allocate space for the second pointer too even if i don't immediately need it?

When you allocate a node, the second pointer is part of that structure, so the pointer itself exists. But malloc() has no idea what the pointers in your node should point to, and it doesn't allocate the memory that line and newLine point to.

I ask if this is a good idea or how to work around it or if it can be polished somehow; maybe immediately after allocating a node I should set newLine to NULL?

If the fields in your node structure are what you need, then it's fine. Setting line and newLine to nil when you create a new node is a good idea so that you won't accidentally dereference a garbage pointer.

A NULL pointer occupies no memory at all or still something compared to not putting any pointer in the struct?

The pointers themselves are part of the node struct, so the take up as much memory as any two pointers. The things that line and newLine point to use as much memory as they need. If line and newLine are nil, then they don't point to anything and of course no memory is used. You could have a thousand pointers all pointing to the same block of memory, and the space needed would be still just the size of that block and the space occupied by the pointers themselves. Try to distinguish between a pointer, which is just an address, and the data at that address; they're completely different things.

So about efficiency, this can be good to avoid creating new nodes and copying in all the data, because just allocating the pointer itself takes very little space i hope?

Yes, a pointer typically takes only 8 bytes on a 64-bit system, so not a lot. But you still have to allocate space for the actual data, so it's not obvious that your approach will be more efficient with respect to space than other methods.

It can be tough to get the hang of pointers at first. The best way to get it is to spend a lot of time with pointers. I'd suggest that you do some exercises to practice, e.g. create a program that breaks some input text into a linked list of words and then sorts the list. To attempt writing a text editor that manipulates blocks of data when your understanding of pointers is shaky is to set yourself up for a world of hurt; time that you spend building your confidence with pointers will pay for itself a hundred times over.