On Fri, Feb 18, 2022 at 02:15:05 +0100, Vincent Lefevre wrote: > Indeed, the code is really strange: > > (c & 0x3000000) >> 12 ^ 0xf8 > > will be stored in a char. So why dealing with bits more significant > than the 8 bits of a char?
I too recently noticed this. I have now made a nice clean patch and submitted that as a new bug: https://savannah.gnu.org/bugs/?62097 > The master branch has a similar code, but with int replaced by > uint32_t, so that the warning disappears just because of the unsigned > type (the behavior becomes fully specified by the C standard instead > of being implementation defined). The master branch looked ok-ish to me, the actualy problem code wasn't there, just the incorrect mask for 4 byte sequences (which does no harm if the value is in range). I would be happy to replace these functions with something easier to read if there is interest.
