(including float80 there seems also right. Not sure that ever exists either, it exists elsewhere in our source...)

I don't think the 80-bit ones can exist in python, but perhaps they can in C?

Should I also get rid of the int128 types, while we're at it?

I don't think the 80-bit ones can exist in python, but perhaps they can in C?

Those are the same thing. The question is if there is any hardware that packs 80bit longdouble into 80bits (i.e. doesn't care about alignment concerns).

Should I also get rid of the int128 types, while we're at it?

Good point, might as well. Since I am pretty sure our build would fail anyway in other places if it existed in practice.

The question is if there is any hardware that packs 80bit longdouble into 80bits

Wouldn't that require sizeof(double) + sizeof(long) == 80, or am I interpreting the long double too literally 🤔? So perhaps a 64-bits double and a 16-bits long on a 16-bit system, if those exist 🤷🏻

hahahaha, sorry but it's funny :). longdouble is a float at least as big as double. 80bits is typical, but it'll be padded for alignment, so its always stord as 96 or 128 bits.

hahahaha, sorry but it's funny :). longdouble is a float at least as big as double. 80bits is typical, but it'll be padded for alignment, so its always stord as 96 or 128 bits.

Lol yea I knew about how it's secretly 80 bits. But I just thought that the padding was a consequence of the double and long sizes, since it's padded to 64+32=96 on 64bit windows, and 64+64=128 on 64bit unix. But no idea if that's actually the reason behind the padding.

the reason behind the padding.

Alignment in memory.

close/reopen

Probably needs a rebase for CI. I can't right now, so feel free to do so if you feel like it

Thanks Joren.