This is the mail archive of the
mailing list for the Archer project.
Re: [python] Implement gdb.search_memory.
El mar, 24-02-2009 a las 08:05 +0000, Phil Muldoon escribiÃ:
> Jan Kratochvil wrote:
> > .././gdb/python/python.c:393: error: passing argument 3 of âPyObject_AsReadBufferâ from incompatible pointer type
> > /usr/include/python2.5/abstract.h:
> > PyAPI_FUNC(int) PyObject_AsReadBuffer(PyObject *obj,
> > const void **buffer,
> > Py_ssize_t *buffer_len);
Strange, I have the same prototype in that header file here (I use
Debian lenny's python2.5-dev version 2.5.2-15, btw) and compilation is
The problem seems to be that our compilers have their nitpicking levels
set to different values. Perhaps someone could tell me how I can make my
compiler behave like Fedora's? I'm using:
% gcc --version
gcc (Debian 4.3.3-3) 4.3.3
I have a set of commits which I was just about to push, but I'll hold
off for now to avoid triggering your additional alarms there.
> > Could you please check-in something backward/forward compatible?
This is not the issue here, it seems. But do we want to enforce
backward/forward compatibility for each pushed commit? We'd have to ask
everybody to compile their changes against the three different python
versions that configure currently detects before they push to the
> I needed to merge some code over to the archer-tromey-python branch
> today and wanted a clean compile before I did so. I checked in these
> fixes to the above warning, and one other.
> Please check the latter case,
> I'm not sure if setting the buffer to NULL will lead to correct results
> in a failure condition.
Well, it doesn't make things worse than what they already were. I
couldn't find a place which says what should happen to ptrptr in case of
an error. Perhaps we shouldn't touch it. I'll make the change.
Thiago Jung Bauermann
IBM Linux Technology Center