TRUE/FALSE vs true/false

From: Boszormenyi Zoltan <zb(at)cybertec(dot)at>
To: pgsql-hackers(at)postgresql(dot)org
Subject: TRUE/FALSE vs true/false
Date: 2011-08-04 10:08:21
Message-ID: 4E3A6F95.3030104@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

I looked at b4fbe392f8ff6ff1a66b488eb7197eef9e1770a4
and I noticed that it's using TRUE, FALSE, true and false
inconsistently:

@@ -248,6 +249,7 @@ CreateSharedInvalidationState(void)
shmInvalBuffer->procState[i].nextMsgNum = 0; /* meaningless */
shmInvalBuffer->procState[i].resetState = false;
shmInvalBuffer->procState[i].signaled = false;
+ shmInvalBuffer->procState[i].hasMessages = false;
shmInvalBuffer->procState[i].nextLXID = InvalidLocalTransactionId;
}
}

@@ -316,6 +316,7 @@ SharedInvalBackendInit(bool sendOnly)
stateP->nextMsgNum = segP->maxMsgNum;
stateP->resetState = false;
stateP->signaled = false;
+ stateP->hasMessages = false;
stateP->sendOnly = sendOnly;

LWLockRelease(SInvalWriteLock);

@@ -459,6 +461,19 @@ SIInsertDataEntries(const SharedInvalidationMessage *data, int n)
SpinLockRelease(&vsegP->msgnumLock);
}

+ /*
+ * Now that the maxMsgNum change is globally visible, we give
+ * everyone a swift kick to make sure they read the newly added
+ * messages. Releasing SInvalWriteLock will enforce a full memory
+ * barrier, so these (unlocked) changes will be committed to memory
+ * before we exit the function.
+ */
+ for (i = 0; i < segP->lastBackend; i++)
+ {
+ ProcState *stateP = &segP->procState[i];
+ stateP->hasMessages = TRUE;
+ }
+
LWLockRelease(SInvalWriteLock);
}
}

@@ -499,11 +514,36 @@ SIGetDataEntries(SharedInvalidationMessage *data, int datasize)
...
+ * Note that, if we don't end up reading all of the messages, we had
+ * better be certain to reset this flag before exiting!
+ */
+ stateP->hasMessages = FALSE;
+

@@ -544,10 +584,16 @@ SIGetDataEntries(SharedInvalidationMessage *data, int datasize)
...
if (stateP->nextMsgNum >= max)
stateP->signaled = false;
+ else
+ stateP->hasMessages = TRUE;

Also, grepping for checking for or assigning bool values reveal that
"true" and "false" are used far more than "TRUE" and "FALSE":

[zozo(at)localhost backend]$ find . -name "*.c" | xargs grep -w true | grep -v 'true"' | grep
= | wc -l
2446
[zozo(at)localhost backend]$ find . -name "*.c" | xargs grep -w false | grep -v 'false"' |
grep = | wc -l
2745
[zozo(at)localhost backend]$ find . -name "*.c" | xargs grep -w TRUE | grep -v 'TRUE"' | grep
= | wc -l
119
[zozo(at)localhost backend]$ find . -name "*.c" | xargs grep -w FALSE | grep -v 'FALSE"' |
grep = | wc -l
140

Shouldn't these get fixed to be consistent?

Best regards,
Zoltán Böszörményi

--
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de
http://www.postgresql.at/

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Boszormenyi Zoltan 2011-08-04 12:13:18 New WIP patch for cross column statistics Re: TEXT vs PG_NODE_TREE in system columns (cross column and expression statistics patch)
Previous Message Pavel Stehule 2011-08-04 09:12:55 Re: Postgres / plpgsql equivalent to python's getattr() ?