Compiler error with static vars/functions

H. S. Teoh hsteoh at quickfur.ath.cx
Fri Feb 10 09:43:03 PST 2012


On Fri, Feb 10, 2012 at 04:38:12PM +0100, Artur Skawina wrote:
> On 02/10/12 16:18, Don Clugston wrote:
> > On 10/02/12 16:08, Artur Skawina wrote:
[...]
> >> No, having non-lower case filenames would just lead to problems.
> >> Like different modules being imported depending on the filesystem
> >> being used, or the user's locale settings.
> > 
> > I don't think it's possible without deliberate sabotage. You can't
> > have two files with names differing only in case on Windows. And
> > module declarations acts as a check anyway.
> 
> What if you have two modules in the import path, eg a "thread"
> provided by some library and another "Thread" elsewhere? Now "import
> Thread;" will do different things depending on the filesystem on which
> "Thread.d" resides.  It simply can't work, it would be great if no
> filesystem tried to muck with the case, but unfortunately they do.
> The compiler should probably enforce module names to be plain ascii
> and lower case every filename before trying to access it. Having
> mixed-case *module* names makes sense, just not the filenames.
[...]

Currently the following code works:

	//---- Б.d ----
	string Ж() {
		return "Жаба";
	}

	//---- main.d ----
	import std.stdio;
	import Б;
	void main() {
		auto Ш = Ж();
		writeln(Ш);
	}

Now, this is on a Linux system with UTF-8 locale. I've no idea what
would happen if this was attempted on a non-UTF8 locale, or on a
filesystem that doesn't support UTF-8 filenames, say on Windows. If the
UTF-8 of a particular module name just *happens* to be binary-equal to
another module name in the native system encoding (non-UTF8), then we
could have a rather nasty problem.


T

-- 
GEEK = Gatherer of Extremely Enlightening Knowledge


More information about the Digitalmars-d-learn mailing list