This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vladris
Recipients PeterASilva, amaury.forgeotdarc, belopolsky, meador.inge, vladris
Date 2011-09-07.00:12:38
SpamBayes Score 2.3858693e-13
Marked as misclassified No
Message-id <1315354358.94.0.409947550163.issue5149@psf.upfronthosting.co.za>
In-reply-to
Content
I believe there is a deeper issue here in ctypes design. Basically we provide both c_char_p and POINTER(c_char) which should behave exactly the same since both are the equivalent of char* in C but internally they have different implementations.

c_char_p is considered a "simple type" and I believe supports some conversions to and from Python strings while POINTER(c_char) is considered a pointer type which supports assignment from array etc.

I think a better fix would be to deprecate p_char_p or make it an equivalent of POINTER(c_char), otherwise we will have to do work on c_char_p to make it more like POINTER(c_char) when issues like this get opened and probably also make POINTER(c_char) more like c_char_p. Why not just have POINTER(c_char) which works as expected? I don't have all the historical context on why this pseudo-simple type was provided but I saw a couple of issues where people expect it to behave like a C char* but it won't because it is implemented as a convenience type with limited support.
History
Date User Action Args
2011-09-07 00:12:39vladrissetrecipients: + vladris, amaury.forgeotdarc, belopolsky, PeterASilva, meador.inge
2011-09-07 00:12:38vladrissetmessageid: <1315354358.94.0.409947550163.issue5149@psf.upfronthosting.co.za>
2011-09-07 00:12:38vladrislinkissue5149 messages
2011-09-07 00:12:38vladriscreate