Date: Tue, 19 Sep 1995 13:41:23 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: bakul@netcom.com (Bakul Shah) Cc: hsu@cs.hut.fi, freebsd-hackers@freefall.freebsd.org Subject: Re: Policy on printf format specifiers? Message-ID: <199509192041.NAA10620@phaeton.artisoft.com> In-Reply-To: <199509191558.IAA09962@netcom15.netcom.com> from "Bakul Shah" at Sep 19, 95 08:58:24 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > Yes, and I also think that 640kbytes of memory is certainly enough for > > anything you would want to do with your computer. > > Cute but it misses the point. If N bytes are enough, using > 2N bytes for a benefit that one won't see for ages, if ever, > is a waste for any value of N. Especially when there is an > immediate cost of doing so [allocating twice as much memory > means you will take twice as many page faults etc. etc.]. > Make a few decisions like this and you'll have slow moving > monster programs for which 640Mbytes won't be enough. Re: wchar_t as 16 bits vs. 32 bits and it's presence in the kernel. The Win95 long file name support uses 16 bit process-encoded Unicode characters for file name storage of long file names. The WinNT file system uses 16 bit process-encoded Unicode characters for file name storage of *all* file names, both long and short. If you ever hope to support mounting of Win95 file systems with exposure of the long names, or if you ever expect to support mounting of WinNT file systems, then you need 16 bit process encoded Unicode strings in the kernel. Period. You will not be able to accomplish component name lookup otherwise. I don't really care whether I have to add additional unsigned short based functions or not, though using wchar_t as a 16 bit unsigned value would save a lot of code duplication and kernel bloat. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509192041.NAA10620>