Messages in this thread | | | From | (Matthias Urlichs) | Subject | Re: Unicode, kernels, Linux and NT (Re: unicode (char as abstract data type)) | Date | 21 Apr 1998 11:51:49 +0200 |
| |
Stephen Williams <steve@icarus.icarus.com> writes: > > And under Windows NT for exactly the same device. (Notice the UNICODE > handling shit^h^h^htuff): > ... which doesn't mean much except that the NT API for multibyte strings is fucked up. Let me demonstrate:
> #define dev_name_str L"\\Device\\ise" [...] > dev_name.Buffer = dev_name_buf; > dev_name.MaximumLength = sizeof(dev_name_buf); > dev_name.Length = 0; > RtlZeroMemory(dev_name_buf, sizeof dev_name_buf); > RtlAppendUnicodeToString(&dev_name, dev_name_str); [...] > RtlIntegerToUnicodeString(num, 10, &number); [...]
> So I wonder which version our European/Asian/Martian friends would rather > write?
You're being unfair. The #define above already _is_ the Unicode string. All NT adds to that is a fair bit of fucking around with string-buffers-which- -carry-current-and-max-length, and replaces sensible functions like sprintf(..."%d"...) (which could easily be extended to be able to accept string buffers as optional source arguments (with a new modifier), if anybody really cared) with a lot of Rtl*() crap.
The whole of that code could easily be replaced with a single
UNICODE sbuf = EMPTY_UNICODE_BUF(100); if(!sbufprint(&sbuf, L"%s%d", dev_name_str, number)) { /* bail out, buffer too short */ } [ continue as in Linux example, pretty much ]
It can't be _that_ difficult to have a sprintf()-workalike in the kernel, not even one that prints to buffers instead of (multibyte) character pointers. And if you really need such a buffer as a string source, use "%Bs" instead of "%s". Or whatever.
-- Matthias Urlichs noris network GmbH
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |