homepage

GCC error when using unicodeobject.h
This ist my first attempt to test an extension with python 3.3. I've been using the 3.3.0a4 tarball.
I'm using very strict compiler settings when compiling my extension modules, especially -Wall -Werror (along with a lot more flags, like -pedantic, -std=c89).
Including Python.h includes unicodeobject.h which emits:
/usr/include/python3.3/unicodeobject.h:905: error: type of bit-field 'overallocate' is a GCC extension
/usr/include/python3.3/unicodeobject.h:908: error: type of bit-field 'readonly' is a GCC extension
Maybe these should just be (unsigned) ints or something?

It might not matter if it's an extension that everyone implements.

Compilation with gcc -std=c89 is not supported. Just drop this option. While Python strives to use C89, we will not distort to meet some abstract language compliance goal. 
OTOH, I fail to see why they need to be bitfields: a plain unsigned char field should work as well (as would an int bitfield). Victor?

I'm not talking about compiling python but my extension module. I *do* try supporting c89. Also relying on implementation extensions is bad style.
I think, there's a huge difference between public header files (standards are good) and linked C code (do whatever you like, although standards are good here as well). OTOH, is there a real difference between char:1 and int:1? That's what we're actually discussing here. If not, I suggest simply using int:1 and be done with it.

New changeset 09736ae1c314 by Victor Stinner in branch 'default':
Issue #14993: Use standard "unsigned char" instead of a unsigned char bitfield
http://hg.python.org/cpython/rev/09736ae1c314 

> OTOH, I fail to see why they need to be bitfields: a plain
> unsigned char field should work as well (as would an int bitfield). Victor?
I chose a bitfield to have a more compact structure. I didn't know that a bitfield using unsigned char is a GCC extension: it compiles on Visual Studio 2008, isn't it?
The size of _PyUnicodeWriter doesn't really matter, so I replace the two fields with simple types.

I don't think the change had any effect on memory consumption: because of alignment, padding is inserted either way to fill the flags to four (32-bit) or eight bytes. So with the bit field, there were 7 bytes of padding on 64-bit systems, and now there are only 6 bytes of padding.
Yes, Visual C also supports the same extension. See the "Microsoft specific" section in
http://msdn.microsoft.com/en-us/library/yszfawxh(v=vs.80).aspx 

> I don't think the change had any effect on memory consumption: because of alignment, padding is inserted either way to fill the flags to four (32-bit) or eight bytes. So with the bit field, there were 7 bytes of padding on 64-bit systems, and now there are only 6 bytes of padding.
Oh, interesting information. I forgot the alignment thing.
> Yes, Visual C also supports the same extension. See the "Microsoft specific" section in
> http://msdn.microsoft.com/en-us/library/yszfawxh(v=vs.80).aspx
Oh, what is the "C" language nowadays?...