Thorsten Froehlich wrote:

> In article <36C### [at] geocitiescom> , "Jon A. Cruz"
> <jon### [at] geocitiescom> wrote:
>
> > With wchar_t itself you get the same issue as with the float/double
> > conversions  and int size. It's designated to contain Unicode characters, but
> > may or may not be 16-bits. Some systems are reported to be using 32-bits for
> > processor efficiency, so just imagine if I pass an array of 16-bit values to a
> > C call expecting 32-bit values.
> >
> > So, that's why I start with wchar_t. If, however, no wide-char API calls are
> > made, then USHORT should be no problem.
>
> There are no C calls that expect it, wchar_t is a C++ keyword and there is
> no standard C library that will expect or take it.
>

But it is in C. It is in Normative Addendum 1. I was just using that as an example.
People working on internationalization stuff on Windows or Intel Linux might assume
16-bit when it gets 32 bits. Also, besides the standard, it is possible for people
to write routines (like the ones I did in uniutils.c) that operate on theses, and
then the difference would matter. That is what will probably have the most impact,
so the proper considerations should be made. That's all.

Post a reply to this message