[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: simulation advice

On 4/4/07, David Kerber <dkerber@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: 
I guess I should stop arguing this; I can live and work with either one as
long as I know what's expected, even if it's not how I would have designed
it...


It's strongly preferred that .cc be used for C++ programs instead of .C.

Even so, case-sensitive filesystems have one thing that
case-insensitive filesystems lack: virtually automatic support for
UTF-8-encoded names with an absolute minimum of code to do it.  It can
implement this with dumb byte-by-byte comparisons.  Either a chunk of
memory matches, or it doesn't.

Otherwise, you'll need to support crazy internationalization APIs when
doing even the simplest of directory manipulations.  For example,
using toupper() to uppercase a filename for comparison purposes in
OS/2 was _strongly_ discouraged because it failed to properly handle
internationalization.  Instead, they had a custom API just for this
one, and only one, purpose: DosMapCase() if I recall correctly.  I
suspect Windows will have something similar.  And I'm willing to bet
you that the code behind DosMapCase() is more than a kilobyte in size,
not counting all the internationalization tables.

This leads to an interesting conundrum: if you need crazy
internationalization functions to properly match filenames, but the
internationalization database resides on disk, now you need a
_default_ locale for the filesystem layer, thus now duplicating data
and code further, something with which to bootstrap the desired locale
with!  Ouch.

I agree that case preservation is a good thing; however, a full
case-insensitive implementation is not worth the time investment to
"Get It Right For Everyone."(tm)

--
Samuel A. Falvo II


_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user