Hi Vlad,

On Thu, Sep 1, 2011 at 1:30 PM, Vlad Riscutia <report@bugs.python.org> wrote:

> Vlad Riscutia <riscutiavlad@gmail.com> added the comment:
>
> Well currently we pack bitfields with an algorithm that uses #ifdefs for GCC and MSVC builds. This feature tries to remove the
> hardcoded behavior and implement it as a runtime option. This should improve interop with other compilers. Currently I provided these
> for MSVC-style and GCC-style bitfield allocations. These, of course, can be extended with other strategies.

Yup, I understand what the feature is doing.  I just wanted to
reiterate (as I am sure you already know) that typically the rules for
implementing bit fields in a particular compiler are pretty complex.
I just wanted to make sure that the use cases are out there to justify
the complexity.  issue11920 really does seem like a use case where
someone would otherwise be stuck without a runtime configurable
allocation strategy.

BTW, out of curiosity I explored the packed case that I mentioned
earlier with GCC more (reproduction case attached):

[meadori@motherbrain ctypes]$ make clean; make
rm -f foo.o libfoo.so.1.0
gcc -Wall -fPIC  -c foo.c
gcc -shared -Wl,-soname,libfoo.so.1 -o libfoo.so.1.0 foo.o
python repro.py
In Python: (85, 85)
From C: (85, 85)
From Python: (85, 85)
[meadori@motherbrain ctypes]$ make clean; CFLAGS=-DPACK=1 make
rm -f foo.o libfoo.so.1.0
gcc -Wall -fPIC -DPACK=1 -c foo.c
gcc -shared -Wl,-soname,libfoo.so.1 -o libfoo.so.1.0 foo.o
python repro.py
In Python: (85, 85)
From C: (85, 85)
From Python: (85, 170)

This shows that there are already cases that can't be handled with
packed bit fields and GCC.  This runtime configuration feature, could
fix this case as well.  However, it is probably better to wait for a
real world use case before implementing some pathological case that I
cooked up ;-)

> Wouldn't a GCC44 constant provided at API level be better than saying "you can't interop with anything build with GCC 4.4 and up"? Or > vice-versa, anything built with GCC < 4.4.

Yeah, probably so.  I think the compiler constraint I stated before is
probably a bit too strong.  I need to think about it more.  But,
again, my point is that there are a lot of different variations when
it comes to bit field allocations.  I don't think we want to end up
implementing all of them.