I realized the problems about not making explicit argument return
types, and made _almost_ all of them explicit over a _year_ ago in
r6653 (by adding the `prototypes` directory where all interactions
with C functions were defined).  Good to see that Shapely got around
to eventually doing that, rather than the haphazard fixes they were
implementing up to this point that never really addressed the
underlying issues.

The reason I said "almost" is that I purposely did not do this for
routines that return strings allocated within GEOS.  If you specified
the response type as `c_char_p` then ctypes would convert to a Python
object (str) when given to a ctypes error check function.  In other
words, because I was doing the proper thing and using the error check
function it is not possible to set the response type to `c_char_p`
_and_ get the pointer address to the string because all you got was a
Python str instead.  It's important to get the pointer address,
otherwise I could not free the string memory allocated inside the GEOS
library -- in other words, GeoDjango would leak memory every time one
serialized to WKT if I didn't do it this way (that's bad).

While it's not possible to get the pointer address when using
`c_char_p` as the restype, I've since figured out that if you use a
simple _subclass_ of `c_char_p` and use that for the response type I
can get access to both the string value and the pointer address to be
freed.

I've implemented this patch in my minor refactor of the GEOS interface
for 1.1 [1]. I've also created a ticket [2] and I'll attach a patch
with the fix, which I'll commit to trunk and the 1.0.X branch within a
week.

And now I realized why I couldn't reproduce on CentOS -- I was using a
32-bit version; forgot to ask "what architecture", d'oh.

-Justin

[1] http://geodjango.org/hg/gis-geos
[2] http://code.djangoproject.com/ticket/9747