Left-shifting by an amount which is more or equal to the type's width is undefined in both C and C++. This could happen in BitStreamWriter when m_bitWrited was zero, and resulted in inconsistent results between Intel and ARM targets.
On Intel, the amount of bits to shift is explicitly masked to its lower 5 (for 32-bit values) or 6 (for 64-bit values) bits. This is documented in the instruction set reference. Effectively, the amount of bits to be shifted is the actual amount modulo 32 or 64. In this particular case, asking the CPU to shift by 32 bits left the value unchanged.
ARM does not place any requirements on the behaviour of the CPU when the amount to shift is larger than 32/64 - the instruction set reference just says that the register is supposed to be "holding a shift amount from 0 to 31 in its bottom 5 bits. ". However, MSVC documentation suggests that values in registers might appear to "wrap around" when shifting by more than 32 or 64 bits, which is indeed what was observed here.
The fix essentially amounts to emulating Intel behaviour (as it was the original development platform and presumably most assumptions were made with it in mind, even if unknowingly) by not touching the value if the amount of bits to shift is 32.
AddString's documentation clearly says that its second parameter is supposed to
be the number of characters to display. Since the vector returned by toWide() is
always null-terminated and the termination character is included in its size(),
this resulted in AddString() treating the termination character as something it
is supposed to actually draw.
Perhaps some versions of AddString() explicitly stop at the termination
character and don't process any further characters : this is probably why this
issue has gone unnoticed for so long.
Fixes#598
As per ECMA 167 [8.3.1 File Set Descriptor Sequence], there should be a Terminating Descriptor after the File Set Descriptor
Plus renaming "ExtentFile" to "ExtendedFileEntry" to comply with UDF 2.50 / ECMA 167 name.
UDF 2.50 specification [6.10.1 Use of UDF on CD-R media] states: "ECMA 167 requires an Anchor Volume Descriptor Pointer (AVDP) at sector 256 and either N or (N - 256), where N is the last recorded Physical Address on the media. UDF requires that the AVDP be recorded at both sector 256 and sector (N - 256) when each session is closed."
As both ImgBurn and DVDFab do not incude the (N - 256) Anchor Volume Decritpor, it seems preferable to omit this descriptor for compatibility with medias and players.
As per UDF specification [2.2.4.3 struct EntityID DomainIdentifier] "The IdentifierSuffix field of this EntityID contains SoftWriteProtect and HardWriteProtect flags."
As per UDF 2.5 standard [2.2.4.3 struct EntityID DomainIdentifier], "The IdentifierSuffix field of this EntityID contains SoftWriteProtect and HardWriteProtect flags."
