On 2008-11-21 18:36, Adam Olsen wrote: > On Fri, Nov 21, 2008 at 7:14 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: >> On 2008-11-20 20:34, Roger Binns wrote: >>> M.-A. Lemburg wrote: >>>> Whether you write: >>>> {PyObject_HEAD_INIT(0), 0, ... >>>> or >>>> {PyVarObject_HEAD_INIT(0, 0), ... >>>> for your type definition doesn't really make much difference. >>> Actually in Py 3 it does. If you use the former (which is how Py 2 does >>> it) then you get serious compiler warnings due to misaligned fields in >>> Py 3 and presumably even worse if run the code. >> You might get warnings (esp. from GCC), but I have yet to see a compiler >> that doesn't map the above to the same memory. >> >> After all, Python 2 has been using this layout for years without any >> compiler warnings or segfaults because of this. > > The definition of PyObject_HEAD_INIT and PyVarObject_HEAD_INIT > changed. We've gone from a series of common fields to a single struct > containing the fields. With the series of fields using > PyObject_HEAD_INIT followed by a size was perfectly correct, but with > a struct it's gibberish.
Sigh... Python 2.5: ----------- (gdb) print PyUnicode_Type $2 = {ob_refcnt = 1, ob_type = 0x6404c0, ob_size = 0, tp_name = 0x505972 "unicode", tp_basicsize = 48, tp_itemsize = 0, tp_dealloc = 0x470500 <unicode_dealloc>, tp_print = 0, tp_getattr = 0, tp_setattr = 0, tp_compare = 0, tp_repr = 0x4746c0 <unicode_repr>, tp_as_number = 0x644f60, tp_as_sequence = 0x644f00, tp_as_mapping = 0x644ee0, ... (gdb) print &PyUnicode_Type.tp_name $3 = (const char **) 0x642758 (gdb) print &PyUnicode_Type.ob_refcnt $4 = (Py_ssize_t *) 0x642740 Python 3.0: ----------- (gdb) print PyUnicode_Type $1 = {ob_base = {ob_base = {ob_refcnt = 1, ob_type = 0x733940}, ob_size = 0}, tp_name = 0x4f52e9 "str", tp_basicsize = 56, tp_itemsize = 0, tp_dealloc = 0x42af80 <unicode_dealloc>, tp_print = 0, tp_getattr = 0, tp_setattr = 0, tp_compare = 0, tp_repr = 0x431ca0 <unicode_repr>, tp_as_number = 0x736420, ... (gdb) print &PyUnicode_Type.tp_name $3 = (const char **) 0x735bf8 (gdb) print &PyUnicode_Type.ob_base $4 = (PyVarObject *) 0x735be0 In both cases, the fields are 24 bytes apart (on my 64-bit machine). Yes, it's a different way of writing and accessing the resp. fields. No, it's not a different memory layout. Yes, this is binary compatible. No, this is not going to help you, since the rest of Python 3 is not ;-) Fortunately, you only rarely have to access the fields in question directly in extensions. And Python 3.0 and 2.6 also add a few macros for abstracting this: #define Py_REFCNT(ob) ... #define Py_TYPE(ob) ... #define Py_SIZE(ob) ... -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 21 2008) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2008-11-12: Released mxODBC.Connect 0.9.3 http://python.egenix.com/ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com