[parted-devel] How are you ever supposed to use the _FIRST_ and _LAST_ macros in disk.h ?
Adam Williamson
awilliam at redhat.com
Mon Jun 20 20:26:43 BST 2022
Hi folks!
So, I was trying to fix pyparted in Fedora Rawhide, and it kinda
snowballed to a point where I'm staring at the _FIRST_ and _LAST_
macros in disk.h and wondering how they're ever supposed to work.
There are three places in disk.h that work basically like this:
enum _PedDiskTypeFeature {
PED_DISK_TYPE_EXTENDED=1, /**< supports extended partitions */
PED_DISK_TYPE_PARTITION_NAME=2, /**< supports partition names */
PED_DISK_TYPE_PARTITION_TYPE_ID=4, /**< supports partition type-ids */
PED_DISK_TYPE_PARTITION_TYPE_UUID=8, /**< supports partition type-uuids */
};
#define PED_DISK_TYPE_FIRST_FEATURE PED_DISK_TYPE_EXTENDED
#define PED_DISK_TYPE_LAST_FEATURE PED_DISK_TYPE_PARTITION_TYPE_UUID
pyparted tries to use these. For instance, in its C module code, it
does a lot of this:
#if PED_PARTITION_LAST_FLAG > 20
PyModule_AddIntConstant(m, "PARTITION_LINUX_HOME", PED_PARTITION_LINUX_HOME);
#endif
However, this does not actually work, because of the problem explained
here: https://stackoverflow.com/questions/34677148
enums are handled by the compiler, so at preprocessor time, all the
enum values effectively evaluate to 0. That check will never 'succeed',
and pyparted will never actually add that constant. This is easy to
check: build pyparted 3.12.0 against current parted and check if the
`_ped` module you get actually has a `PARTITION_LINUX_HOME` attribute.
It won't. (You can even check this in Fedora Rawhide's current
pyparted...)
Up until 3.12.0, pyparted did this instead, as the stackoverflow thread
suggests:
if (PED_PARTITION_LAST_FLAG > 20) {
PyModule_AddIntConstant(m, "PARTITION_LINUX_HOME", PED_PARTITION_LINUX_HOME);
}
However, it turns out *that* doesn't really work either. If you
actually try and build that code with an older parted, the build fails.
I wrote a similar check into my patch to try and make pyparted work
with parted 3.5:
if (PED_DISK_TYPE_LAST_FEATURE > 2) {
PyModule_AddIntConstant(m, "DISK_TYPE_PARTITION_TYPE_ID", PED_DISK_TYPE_PARTITION_TYPE_ID);
PyModule_AddIntConstant(m, "DISK_TYPE_PARTITION_TYPE_UUID", PED_DISK_TYPE_PARTITION_TYPE_UUID);
}
and that works great building against 3.5, but if you try and build
that against parted 3.4, it fails - the compiler still wants
PED_DISK_TYPE_PARTITION_TYPE_ID and PED_DISK_TYPE_PARTITION_TYPE_UUID
to be defined, even though they're in the if block:
src/_pedmodule.c: In function ‘PyInit__ped’:
src/_pedmodule.c:689:63: error: ‘PED_DISK_TYPE_PARTITION_TYPE_ID’ undeclared (first use in this function); did you mean ‘PED_DISK_TYPE_PARTITION_NAME’?
689 | PyModule_AddIntConstant(m, "DISK_TYPE_PARTITION_TYPE_ID", PED_DISK_TYPE_PARTITION_TYPE_ID);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| PED_DISK_TYPE_PARTITION_NAME
src/_pedmodule.c:689:63: note: each undeclared identifier is reported only once for each function it appears in
src/_pedmodule.c:690:65: error: ‘PED_DISK_TYPE_PARTITION_TYPE_UUID’ undeclared (first use in this function); did you mean ‘PED_DISK_TYPE_PARTITION_NAME’?
690 | PyModule_AddIntConstant(m, "DISK_TYPE_PARTITION_TYPE_UUID", PED_DISK_TYPE_PARTITION_TYPE_UUID);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| PED_DISK_TYPE_PARTITION_NAME
so if you can't use these _LAST_ macros at preprocessor time or at
compile/run time, how *can* you ever use them? Am I missing something?
If I'm not missing anything...see the attached patch, I guess?
I'm not subscribed to the list, so please CC me on replies - thanks!
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Set-_FIRST_-and-_LAST_-macro-values-in-disk.h-direct.patch
Type: text/x-patch
Size: 2761 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/parted-devel/attachments/20220620/216530ba/attachment.bin>
More information about the parted-devel
mailing list