Andrew Black wrote: [...]
The call stack when the assertion dialog is presented is as follows, but I don't find it to be very helpful:
Thanks. Even if it doesn't seem helpful it's good to include a stack trace when discussing a crash in an involved piece of code. It uniquely identifies the crash site, including the context, and often makes it possible for others to determine whether a similarly looking crash is or isn't due to the same problem. [...]
You would be in a better position to determine the correct course of action than I am. The drawback of using a 32 bit datatype would be being unable to use the system wchar_t functions, while the drawback of staying with the native wchar_t would be the loss of the upper segment of the character map.
Yes, but that'll end up getting lost in any case. It just a matter of at which stage it happens (on input, during processing or on output to the locale database).
My instinct is to use the wider datatype, but I don't know how efficient it would be to replace the entire set of system wchar_t functions. (OS X 10.2 was lacking in wchar_t functions if I recall correctly, and we never really got the library compiling there.)
Using a 32-bit type throughout the utilities (except for output) would (or should) let us use the same code paths regardless of the width of wchar_t. And unless we are using some of the wide string functions (like wcstombs) as opposed to sticking to their single character versions (like wctomb) it should be possible to continue to use them without a change. Martin
