[cairo] return value of _cairo_composite_rectangles_intersect()

Bill Spitzak spitzak at gmail.com
Mon Dec 21 09:11:50 PST 2015


On Sat, Dec 19, 2015 at 10:06 AM, Enrico Weigelt, metux IT consult <
enrico.weigelt at gr13.net> wrote:

If C had constrainted subtypes, all of this would be pretty easy - we
> could let those functions return a subtype, which is constrainted to
> exactly the allowed values, so the compiler could check for that.
>

I don't think undefined values are any problem. They will pass through
unchanged in most code. Also I think you can pretty clearly state that
functions that return values outside this set even if they call functions
that all only return values inside the set, are in error.

The real problem is with the status is the inconsistency with true/false,
making it too easy to write code that does the wrong thing, or that is hard
to read. It would help if software was forced to write "foo() == OK", or to
just make "if (status)" actually be true only when status is OK. But that
can't be done with C, and even though C++ can make this happen it usually
is not done that way, probably because it is still hard to read and too
easy to make a mistake.

Hmm, I don't think it's really consistent. Okay, you can simply pass the
> value up in the call hierarchy - but is that really so helpful ?
>

That is actually pretty common:

   int status;
   status = foo();
   if (status != OK) return status;
   status = bar();
   if (status != OK) return status;
   status = baz();
   return status;

This also works if boolean success value is used consistently. But it gets
difficult if there is a mix of types, which is probably why you are seeing
resistance to changing some (but not all) functions to bool.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cairographics.org/archives/cairo/attachments/20151221/e251ed30/attachment-0001.html>


More information about the cairo mailing list