[FFmpeg-devel] [RFC][PATCH] Windows Television (WTV) file system handling
Sat Jan 22 12:02:13 CET 2011
On Sat, Jan 22, 2011 at 09:20:20PM +1100, Peter Ross wrote:
> > > I do not know of any. While there are wchar functions, one cannot rely on
> > > sizeof(wchar_t)==2.
> > If you insist on comparing strings, all strings being compared here
> > are always static strings. This allows for tricks, e.g. declaring them
> > as wchar_t strings, which you apparently don't want to do, or just
> > creating one manually by doing "s\0t\0r\0i\0n\0g"; </ugly>. The
> > advantage of these approaches (easiest is really to look for a
> > wchar-style thing that ensures 16-bit unicode formatting) is that you
> > can use memcmp() instead of this slow compare function, and memcmp()
> > is probably better-optimized. Also saves code.
> You're right, that looks horrid. I have updated to use wcscmp().
I am not really very comfortable of getting into the compatibility
nightmare of wchar_t.
In particular I think you are assuming that wchar is compatible with
UCS-2, but I think that there have been other wchar formats.
> + * Convert 16-bit litte endian string to wchar string
> + * @param[in] src Source string
> + * @param srclen Length of source string in characters
> + * @param[out] dst Detination
> + * @param dstlen Length of destination string (characters)
> + */
> +static void str16le_to_wcs(const uint8_t *src, int srclen, wchar_t *dst, int dstlen)
> + int i;
> + for (i = 0; i < FFMIN(srclen, dstlen - 1); i++)
> + dst[i] = AV_RL16(src + 2*i);
> + dst[i] = 0;
Also you are treating the string as UCS-2, are you really sure it
isn't really UTF-16?
More information about the ffmpeg-devel