[Pixman] [PATCH/RFC 0/4] New option to build pixman as C++ code (--enable-enforced-cplusplus)

[Søren Sandmann]

Siarhei Siamashka <siarhei.siamashka at gmail.com> writes:

> This is not intended to be immediately pushed to pixman git repository.
> At least not until it proves to have some real practical use. Except
> maybe for the 'xor'->'filler' variable rename patch, which clearly
> should not cause any regressions or inconveniences.

There is a number of things in this series that look like good changes
regardless of moving to C++ or not. Some I noticed:

The SIZE_MAX change was requested here:

    http://lists.freedesktop.org/archives/pixman/2012-August/002196.html

and someone recently mailed me privately and pointed out that Solaris 9
doesn't have it either.

The xor->filler change should be harmless as you point out, and 'filler'
probably is a better name than 'xor'.

The uint32->pixman_format_t in pixman-glyph.c looks good.

Regarding the malloc() changes, it might be worthwhile to add some
macros that take a typename as a parameter, along the lines of

       #define pixman_new(type, n)    \
              ((type *)pixman_malloc_ab (sizeof (type), n))

so that we get warnings if we try to assign the result to an incorrect
pointer type. Although for a lot of code in pixman, we do actually rely
on the ability to do type aliasing of malloc()ed memory, so maybe the
usefulness of such macros is limited.

> Any comments or ideas? Hopefully not a C vs. C++ flamewar :)

Every once in a while I let myself be convinced me that C++ can be used
as a better C, but whenever I have tried it, it has somehow always ended
up driving me crazy with longer compile times and casts all over the
place. I guess I could see the potential for better debug builds that
you mention in the first commit message, but I'd definitely like to see
some concrete benefits before committing to keep all pixman code
compilable as C++.


Søren