wchar_t is 32-bit on Linux

[garyww]

wchar_t is 32-bit on Linux and this causes several bugs. When compiling with -fshort-wchar (forces wchar_t to be 16-bit) everything about Joliet parsing fails but all other warnings I got previously (see below) were gone.

LBA[-05000, 0xffffec78]: [F:ReadCDForCheckingPregapSync][L:746]
    Opcode: 0xbe
    ScsiStatus: 0x02 = CHECK_CONDITION
    SenseData Key-Asc-Ascq: 05-24-00 = ILLEGAL_REQUEST - INVALID FIELD IN CDB
lpCmd: be, 04, ff, ff, ec, 78, 00, 00, 01, f8, 04, 00
dwBufSize: 2448
LBA[348300, 0x5508c]: [F:ProcessReadCD][L:318]
    Opcode: 0xbe
    ScsiStatus: 0x02 = CHECK_CONDITION
    SenseData Key-Asc-Ascq: 05-21-00 = ILLEGAL_REQUEST - LOGICAL BLOCK ADDRESS OUT OF RANGE

There were also bugs with Joliet and I assume wherever WCHAR is used, for example https://github.com/saramibreak/DiscImageCreator/commit/4efafee0f06478886fe7672e1d7e40092ec5bf30 was also caused by this.

The problem with -fshort-wchar is that it only exists to help build programs that run under WINE, the various GCC wide char functions always assume bigger wchar_ts. I don't think adding that flag is a good solution. Instead I suggest to use u16string and char16_t for all strings and chars throughout the whole program. I know this would be a big and annoying change but it would guarantee cross-platform support.

PS: DIC is relly great and thanks to it and you I'll submit some dumps soon :)

[saramibreak]

Do you know the structure to get the cd-text? I searched for it in include/linux/cdrom.h and include/uapi/linux/cdrom.h but didn't find it.

[garyww]

I don't know but libcdio can read it so it might be helpful: http://git.savannah.gnu.org/cgit/libcdio.git/tree/lib/driver/cdtext.c