New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GCC error when using unicodeobject.h #59198
Comments
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 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': |
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 |
Oh, interesting information. I forgot the alignment thing.
Oh, what is the "C" language nowadays?... |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: