On 16.05.2012 22:04, Jan Kara wrote: > On Wed 16-05-12 17:14:23, Vladimir 'φ-coder/phcoder' Serbinenko wrote: >> On 16.05.2012 16:34, Jan Kara wrote: >>> On Wed 16-05-12 01:10:22, Vladimir 'φ-coder/phcoder' Serbinenko wrote: >>>> I also have a counterpart for mkudffs/udf-tools but sourceforge homepage >>>> seems to be abandoned does anybody know if there is a new homepage for >>>> mkudffs? > Oh, and I forgot to reply here: mkudffs is really unmaintained. But also > it's not used too much AFAIK. Most people use genisoimage to generate udf > filesystems. But it doesn't seem to be appropriate for non-optical media. >> 0) Homegrown like in previous patch >> 1) Add a new "endianness" UTF16_LITTLE_ENDIAN_UNALIGNED >> 2) Split code for "compressed" vs "uncompressed" and copy the string to >> a temporary buffer in "uncompressed" branch. >> 3) Like 2 but make buffer sliding and contain only 2 elements. >> >> I think 1 or 3 would be the most reasonable. Which solution do you prefer? > I think 1 would be the best since then it can be easily reused by other > filesystems which may have similar issue. > Ok, I'll do it. I've noticed another duplication in the UDF code: there is NLS support and separate UTF-8 support. UTF-8 is support by 2 ways actually: with -o utf8 and -o iocharset=utf8 which imply different codepaths. Specific UTF-8 support is probably slightly faster by avoiding calls and basically doing everything with shifts (or can be made so with a small patch). Should I perhaps kill one of them? Is iocharset!=utf8 still of any importance? I haven't seen it in ages. Perhaps we could keep just the performant UTF-8 support and map iocharset=utf8 to it and drop iocharset!=utf8? iocharset!=utf8 probably has no users anyway so keeping it we're likely to keep bugs and code duplication with no benefit. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko
Attachment:
signature.asc
Description: OpenPGP digital signature
