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 meador.inge
Recipients higstar, meador.inge, terry.reedy, vladris
Date 2011-09-01.17:51:37
SpamBayes Score 6.417972e-11
Marked as misclassified No
Message-id <CAK1Qooq2Ffz2bzW3=shi2TD-Sph1hCXVLNnGyREszOxK3N7Vhw@mail.gmail.com>
In-reply-to <1314888328.47.0.0138570653786.issue6069@psf.upfronthosting.co.za>
Content
On Thu, Sep 1, 2011 at 9:45 AM, Vlad Riscutia <report@bugs.python.org> wrote:

> Vlad Riscutia <riscutiavlad@gmail.com> added the comment:
>
> Meador, I believe this was the first issue on the tracker that got me looking into bitfield allocation.
> I agree that big-endian on MSVC doesn't make too much sense but you can disregard that - using default endianess will still yield
> different sizes of bitfields when compiled with GCC and MSVC.

Sure, but this particular issue is purporting that the layout of the
structure is incorrect, not that the size is.

> Basically bitfield allocation is compiler specific and patch in issue12528 implements a way to select which
> allocation strategy to be used at runtime instead of hardcoding the one with which Python is compiled. This
> should improve cross-compiler interop. I wanted to hyperlink that patch to all other bitfield bugs, that's why I
> followed up with link to the patch.

Yes, it is very compiler specific.  I have some thoughts about making
this configurable, but I will comment on issue12528 with those.

> Feel free to close this, either as not an issue or as a duplicate of issue12528.

I will open a documentation bug and close this one out.
History
Date User Action Args
2011-09-01 17:51:38meador.ingesetrecipients: + meador.inge, terry.reedy, higstar, vladris
2011-09-01 17:51:38meador.ingelinkissue6069 messages
2011-09-01 17:51:37meador.ingecreate