Benjamin.Riefenstahl at epost.de
Mon Mar 8 13:15:53 GMT 2004
tridge at samba.org writes:
> this argument doesn't convince me. As long as we stick to the
> "rules" as to what we can assume about a internal charset then we
> will be OK.
In the current system the rules are not a requirement on "us" but on
the users' file systems out there. And not all of them conform to
those rules, that's a fact.
> *) build a "charset translation" NTVFS module that can be used in
> those less common cases where you wish to use a different charset
> for some shares.
I like that approach. You get your optimizations for filesystems that
conform to your rules, but you can use the charset translation module
for all others.
> On windows they have compiler support for wide characters but we
> don't on unix. Without that compiler support it is a nightmare
> dealing with all of the string constants we have to deal with in
I understand that point. OTOH, there are ways around that, so the
"nightmare" part seems exaggerated to me. Off the top of my head: Use
a simple preprocessor, use global constants and a preprocessor or
generator for the implementation file(s) of those strings, use a
version of sprintf() that takes an ASCII string as format parameter,
but generates UTF-16 (and similar for other functions).
Also, from a quick review, quite a considerable percentage of constant
strings in Samba are not for exchange with SMB, but configuration
options, error messages and other stuff that can just stay in ASCII.
More information about the samba-technical