<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://wiki.inkscape.org/wiki/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=UowNlw</id>
	<title>Inkscape Wiki - User contributions [en]</title>
	<link rel="self" type="application/atom+xml" href="https://wiki.inkscape.org/wiki/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=UowNlw"/>
	<link rel="alternate" type="text/html" href="https://wiki.inkscape.org/wiki/Special:Contributions/UowNlw"/>
	<updated>2026-04-25T02:10:22Z</updated>
	<subtitle>User contributions</subtitle>
	<generator>MediaWiki 1.36.1</generator>
	<entry>
		<id>https://wiki.inkscape.org/wiki/index.php?title=Booleans&amp;diff=14871</id>
		<title>Booleans</title>
		<link rel="alternate" type="text/html" href="https://wiki.inkscape.org/wiki/index.php?title=Booleans&amp;diff=14871"/>
		<updated>2007-06-10T01:56:07Z</updated>

		<summary type="html">&lt;p&gt;UowNlw: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;I've come across a subtle bug that could be in many places in the&lt;br /&gt;
sources. Basically, any comparrisons of booleans might be unsafe.&lt;br /&gt;
&lt;br /&gt;
I first ran across it in sp_document_set_undo_sensitive in&lt;br /&gt;
document-undo.c. In it, the param 'sensitive' is of type gboolean. At&lt;br /&gt;
one point it is compared with doc-&amp;gt;priv-&amp;gt;sensitive. Ok, things seem fine&lt;br /&gt;
so far... however...&lt;br /&gt;
&lt;br /&gt;
The specific types in question come to contribute to the problem. Since&lt;br /&gt;
the code is C and not C  , it uses gboolean instead of bool (of course,&lt;br /&gt;
since bool doesn't really exist in plain C). gboolean, in turn, lives in&lt;br /&gt;
glib's includes (a good place to get things from) and is typedef'd as gint.&lt;br /&gt;
&lt;br /&gt;
That's where the problems come in. Since it's an int, not a true bool,&lt;br /&gt;
any non-zero value is taken as true, and any zero value is taken as&lt;br /&gt;
false. So far that seems OK, but let's take a quick look at some&lt;br /&gt;
possible values:&lt;br /&gt;
&lt;br /&gt;
 0 == false&lt;br /&gt;
 1 == true&lt;br /&gt;
 -1 == true&lt;br /&gt;
 $ffffffff == true&lt;br /&gt;
 ~0 == true&lt;br /&gt;
 4 == true&lt;br /&gt;
&lt;br /&gt;
Now, given all that, this next line of code clearly has some issues:&lt;br /&gt;
&lt;br /&gt;
 if (sensitive == doc-&amp;gt;priv-&amp;gt;sensitive) return;&lt;br /&gt;
&lt;br /&gt;
Let's say that 'sensitive' is set to '~0' (all bits set. a nice safe&lt;br /&gt;
non-false value and often used for TRUE), and that doc-&amp;gt;priv-&amp;gt;sensitive&lt;br /&gt;
is set to 1. Now both integer values represent 'true', however they are&lt;br /&gt;
not actually equal to each other, and that check will fail even when&lt;br /&gt;
both variables are not false.&lt;br /&gt;
&lt;br /&gt;
:-(&lt;br /&gt;
&lt;br /&gt;
Therefore, anywhere two boolean-ish variables are compared for equality&lt;br /&gt;
or inequality they will not always evaluate properly. Additionally,&lt;br /&gt;
since these are just int values of one type or another, they could be&lt;br /&gt;
all over the codebase yet not noticed. (There's not something simple and&lt;br /&gt;
definitive that I can grep all of the code for, otherwise I would have&lt;br /&gt;
tried to find all of them myself).&lt;br /&gt;
&lt;br /&gt;
So the solution would seem to be to have all eyes watching for potential&lt;br /&gt;
problem cases and then fixing them as they are encountered.&lt;br /&gt;
&lt;br /&gt;
However, there is some good news. Doing a check of a single gboolean&lt;br /&gt;
variable is safe, since all non-zero values will be treated as true,&lt;br /&gt;
code will work as expected. It's only the case where two values are&lt;br /&gt;
compared that can have problems.&lt;br /&gt;
&lt;br /&gt;
 if ( sensitive ) // works&lt;br /&gt;
 if ( !sensitive ) // works&lt;br /&gt;
 if ( sensitive&lt;/div&gt;</summary>
		<author><name>UowNlw</name></author>
	</entry>
</feed>