if (text && *text) - ???
 

This is a function from a GTK+ tutorial:

static void toggle_show_text( GtkWidget *widget,
ProgressData *pdata )
{
const gchar *text;

text = gtk_progress_bar_get_text (GTK_PROGRESS_BAR (pdata->pbar));
if (text && *text)
gtk_progress_bar_set_text (GTK_PROGRESS_BAR (pdata->pbar), "");
else
gtk_progress_bar_set_text (GTK_PROGRESS_BAR (pdata->pbar), "some text");
}


Basically I know that it says: if there is text on the progress bar then change to "" else to "some text".

But I don't understand this:
if (text && *text)

Why are there both text and *text in this statement?

checking `text' for non-zero value to make sure that it is pointing to some location, checking `*text' for non-zero value to make sure that it has not reached the end of the string.

-- Adil

text is a pointer to a string - the value of text is either a memory address, or null. The first half of the if tests whether text contains an actual address. testing *text then tests the value at that location - this will succeed if there is any data there, or fail if the string is empty (the value at *text will be 0 to terminate the string)

So if( text && *text ) literally says "if text is a valid pointer AND text points to a non-empty string".

Everything said above is right, just one more interesting thing.
In the statement (text && *text) the second part '*text' will not be evaluated if the first part 'text' is NULL, sometimes called "short circuiting AND logic". This prevents a runtime core dump in the case when text is NULL, because evaluating *(NULL) is not allowed. Normally and logically, AND operations can be performed in any order and get the same result, but not in this case because the second '*text' can not be evaluated if the first part is false.
This is a very important point and a frequent source of software bugs.

Thank you everyone,

The answer given by randyding was what I needed.

Just to confirm that I understand. I can't eveluate *text without evaluating text because that't the rule. The pointer has to be tested before the value that pointer points to is tested. Do I get it right?


Also if I do like that:
if (*text)
then it still compiles, but I get segmentation fault during execution. What exactly happens?

answer to: what happens if you dereference text without testing to see if it's NULL?
 

The compiler will let you dereference the pointer, but if it turns out to be NULL (an invalid address for you to dereference), your program will end abruptly (segmentation fault).

Testing to see if that pointer is NULL or not is not enforced by the compiler, but is never a bad idea. It's a short operation for the computer to perform, and can be the difference between gracefully handling the error or crashing without output.

Even if you know the source of the pointer, the "is this pointer NULL" test (immediately before the pointer's use) is good practice. If the code is shuffled around in the future, or copied by someone else, the source of the pointer may change. For the 2 dead-simple CPU instructions that will compile into (compare and conditional branch), just test the pointer.

-Paul

additional comment re: dereferencing pointers.
 

Just another note while you're reading about what you can and can't do with pointers:

NULL (zero) is not the only value of a pointer that you're not allowed to dereference. Any value of pointer that doesn't fall within a specific range of addresses will cause a segmentation fault when dereferenced (dereferencing, by the way, is the fancy say of saying "we check the contents of the address the pointer is equal to"). An invalid pointer can be the result of an uninitialized variable, incorrect pointer arithmetic, indexing an array improperly, or memory corruption elsewhere in the running process. The first three ways are preventable through good practice and correct code; the last one normally is too, but could potentially be caused by faulty code/libraries elsewhere.

This is an overkill response, I know, but there are going to be novice programmers reading this thread, and these are all good things to know when tracking/avoiding bugs :)

-Paul