mate-session: fix memory leak

[rbuj]

No description provided.

[lukefromdc]

While I do NOT know now to properly test these tools, my normal session with compiz starts up same as always with this installed. I can see the memory management changes though and this should work. I am guessing the const portion of these declarations was being tossed by the compiler at build time due to the expected changes of value at runtime.

[thesquash]

I am guessing the const portion of these declarations was being tossed by the compiler at build time due to the expected changes of value at runtime.

Nope. Most people don't know this, but in C, when you add the const qualifier to a pointer variable, the const applies to the thing to which the pointer references, just like the char type name indicates the size of the data pointed to by the pointer. Thus, a pointer of the form const char * p; points to a character variable, and if you attempt to change the value of that pointed-to variable through the pointer, the compiler will warn you. So all of the following would be illegal (or at least warned against by the compiler):

*p = '\0';
p[0] = '\0';
p[i-1] = '\0';

The const specifier does not apply to the pointer variable itself. You can change what the pointer points to at will, even with the const specifier. This is legal:

char a = 'A', b = 'B', c = 'C';
const char * p = &a;
p = &b;
p = &c;

By the way, if you wanted to make the pointer read-only, so that the pointer itself could not be re-assigned the address of some other variable, I think you can apply the const after the last asterisk, like this:

char * const p = &a;

I'm a little rusty on that last point, but it's either that or immediately preceding the asterisk. I think it's after the asterisk, though.

Just thought I'd clear that up, since if any mysteries exist regarding what program code does, the code isn't really getting reviewed, is it?

[lukefromdc]

Thanks for your explanation of how const was used here, which explains the memory leak. I went to
https://docs.gtk.org/glib/func.clear_pointer.html
which shows g_clear_pointer both destroys the variable and sets the pointer to NULL. This should take care of both the RAM holding the pointer variable and the RAM to which it points, stopping up the leak.

[raveit65]

LGTM