Port Vlad's fixes for integer overflows with malloc().

1 files changed, 71 insertions, 19 deletions

diff --git a/TODO b/TODO
index 92beb0b9..6649c698 100644
--- a/TODO
+++ b/TODO
@@ -1,8 +1,15 @@
+  - Go through things marked FIXME
+
+  - Add calls to prepare and finish access where necessary.  grep for
+    ACCESS_MEM, and make sure they are correctly wrapped in prepare
+    and finish.
+
+  - restore READ/WRITE in the fbcompose combiners since they sometimes
+    store directly to destination drawables.
+
   - It probably makes sense to move the more strange X region API
     into pixman as well, but guarded with PIXMAN_XORG_COMPATIBILITY
 
-  - Go through things marked FIXME
-
   - Reinstate the FbBits typedef? At the moment we don't
     even have the FbBits type; we just use uint32_t everywhere.
 
@@ -14,33 +21,78 @@
         this, I suggest just using 32-bit datatypes by setting
         IC_SHIFT to 5 for all machines.
 
-- Consider whether calling regions region16 is really such a great idea
+  - Consider whether calling regions region16 is really such a great
+    idea Vlad wants 32 bit regions for Cairo. This will break X server
+    ABI, but should otherwise be mostly harmless, though a
+    pixman_region_get_boxes16() may be useful.
 
-- Run cairo test suite; fix bugs
-	- one bug in source-scale-clip
+  - Make source clipping optional.
+      - done: source clipping happens through an indirection.
+	still needs to make the indirection settable. (And call it
+        from X)
 
- - Remove the warning suppression in the ACCESS_MEM macro and fix the
-    warnings that are real
+  - Consider optimizing the 8/16 bit solid fills in pixman-util.c by
+    storing more than one value at a time.
 
-- Add calls to prepare and finish access where necessary. 
-  grep for ACCESS_MEM, and make sure they are correctly wrapped in
-  prepare and finish
+  - Add an image cache to prevent excessive malloc/free. Note that pixman
+    needs to be thread safe when used from cairo.
 
-- Make source clipping optional.
-       - done: source clipping happens through an indirection.
-         still needs to make the indirection settable.
+  - Review the pixman_format_code_t enum to make sure it will support
+    future formats. Some formats we will probably need:
 
-- make the wrapper functions global instead of image specific
-	- this won't work since pixman is linked to both fb and wfb
+    	   ARGB/ABGR with 16/32/64 bit integer/floating channels
+	   YUV2,
+	   YV12
+
+    Also we may need the ability to distinguish between PICT_c8 and
+    PICT_x4c4. (This could be done by interpreting the A channel as
+    the depth for TYPE_COLOR and TYPE_GRAY formats).
+
+    A possibility may be to reserve the two top bits and make them
+    encode "number of places to shift the channel widths given" Since
+    these bits are 00 at the moment everything will continue to work,
+    but these additional widths will be allowed:
+
+    	     All even widths between 18-32
+	     All multiples of four widths between 33 and 64
+	     All multiples of eight between 64 and 128
 
-- restore READ/WRITE in the fbcompose combiners since they sometimes
-  store directly to destination drawables.
+    This means things like r21g22b21 won't work - is that worth
+    worrying about? I don't think so. And of course the bpp field
+    can't handle a depth of over 256, so > 64 bit channels arent'
+    really all that useful.
+
+    We could reserve one extra bit to indicate floating point, but
+    we may also just add 
+
+       	   PIXMAN_TYPE_ARGB_FLOAT
+	   PIXMAN_TYPE_BGRA_FLOAT
+	   PIXMAN_TYPE_A_FLOAT
+    
+    image types. With five bits we can support up to 32 different
+    format types, which should be enough for everybody, even if we
+    decide to support all the various video formats here:
+
+    	        http://www.fourcc.org/yuv.php
+
+    It may make sense to have a PIXMAN_TYPE_YUV, and then use the
+    channel bits to specify the exact subtype.
+
+    What about color spaces such a linear vs. srGB etc.?
 
-- Consider optimizing the 8/16 bit solid fills in pixman-util.c by
-  storing more than one value at a time.
 
 done:
 
+- Run cairo test suite; fix bugs
+	- one bug in source-scale-clip
+
+ - Remove the warning suppression in the ACCESS_MEM macro and fix the
+    warnings that are real
+	- irrelevant now.
+
+- make the wrapper functions global instead of image specific
+	- this won't work since pixman is linked to both fb and wfb
+
 - Add non-mmx solid fill
 
 - Make sure the endian-ness macros are defined correctly.