eden-emu/eden - eden - InfoTonic

Lioncash 9ee475f731 svc: Correct always true assertion case in SetThreadCoreMask The reason this would never be true is that ideal_processor is a u8 and THREADPROCESSORID_DEFAULT is an s32. In this case, it boils down to how arithmetic conversions are performed before performing the comparison. If an unsigned value has a lesser conversion rank (aka smaller size) than the signed type being compared, then the unsigned value is promoted to the signed value (i.e. u8 -> s32 happens before the comparison). No sign-extension occurs here either. An alternative phrasing: Say we have a variable named core and it's given a value of -2. u8 core = -2; This becomes 254 due to the lack of sign. During integral promotion to the signed type, this still remains as 254, and therefore the condition will always be true, because no matter what value the u8 is given it will never be -2 in terms of 32 bits. Now, if one type was a s32 and one was a u32, this would be entirely different, since they have the same bit width (and the signed type would be converted to unsigned instead of the other way around) but would still have its representation preserved in terms of bits, allowing the comparison to be false in some cases, as opposed to being true all the time. --- We also get rid of two signed/unsigned comparison warnings while we're at it.	8 years ago
..
pre-commit	pre-commit: Change comment from citra to yuzu	8 years ago

Lioncash 9ee475f731 svc: Correct always true assertion case in SetThreadCoreMask

The reason this would never be true is that ideal_processor is a u8 and
THREADPROCESSORID_DEFAULT is an s32. In this case, it boils down to how
arithmetic conversions are performed before performing the comparison.

If an unsigned value has a lesser conversion rank (aka smaller size)
than the signed type being compared, then the unsigned value is promoted
to the signed value (i.e. u8 -> s32 happens before the comparison). No
sign-extension occurs here either.

An alternative phrasing:

Say we have a variable named core and it's given a value of -2.

u8 core = -2;

This becomes 254 due to the lack of sign. During integral promotion to
the signed type, this still remains as 254, and therefore the condition
will always be true, because no matter what value the u8 is given it
will never be -2 in terms of 32 bits.

Now, if one type was a s32 and one was a u32, this would be entirely
different, since they have the same bit width (and the signed type would
be converted to unsigned instead of the other way around) but would
still have its representation preserved in terms of bits, allowing the
comparison to be false in some cases, as opposed to being true all the
time.

---

We also get rid of two signed/unsigned comparison warnings while we're
at it.

8 years ago

pre-commit

pre-commit: Change comment from citra to yuzu

8 years ago