I poked around various places and didn't find a good place to search
for what is probably an obscure (and/or blatantly obvious to old
hands) issue.

I created a file d-al.d containing a direct transliteration of one of
my simplest C programs (the // comment illustrates the workaround or
fix when uncommented):

//module com.jlss.cmd.al;

private final char[] rcs = "@(#)$Id$";

import std.c.stdio;

int main(char[][] argv)
{
        int i;
        for (i = 1; i < argv.length; i++)
                puts(argv[i]);
        return 0;
}

The program echoes its command line arguments, one per line - which
can be very useful in debugging (Unix) shell scripts, especially when
the arguments contain spaces.

The problem I ran into using gdc (from d-for-gcc-r1f.tgz, built atop
GCC 3.4.0 on MacOS X 10.3.4) was:

  /var/tmp//cc5HWzTU.s:8:Invalid mnemonic '__D4d-al3rcsAa:'

My diagnosis of the problem is that the source file is used as the module name and embedded into the assembler-level name of the rcs constant string, and when the file name minus '.d' suffix is not a valid identifier, the assembler complains.

As noted, the fix I found was to place an explicit module name at the
top of the file - and it then compiled fine.

So, is this a known problem (I didn't find a reference to the
importance of file names when modules are not explicitly name in the D
Programming Language PDF file dated 2004-01-22), a buglet in the GDC
compiler, or a new finding that can be noted in the annals of D?

(The RCS string is what I use to identify programs - in C, that's:
  static const char rcs[] = "@(#)$Id$";
I'm willing to be told I'm using wholly the wrong mechanism in D.
The @(#) bit is the identifier string used by the SCCS program 'what'
to identify software - I grew up on Unix and SCCS, migrated to RCS
before Y2K, and rather reluctantly at that, and I'm looking at whether
SubVersion is the way of the future.)

-- 
Jonathan Leffler                   #include <disclaimer.h>
Email: jleffler@earthlink.net, jleffler@us.ibm.com
Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/

"Jonathan Leffler" <jleffler@earthlink.net> wrote in message news:cc8cf3$64b$1@digitaldaemon.com...
> As noted, the fix I found was to place an explicit module name at the top of the file - and it then compiled fine.
>
> So, is this a known problem (I didn't find a reference to the importance of file names when modules are not explicitly name in the D Programming Language PDF file dated 2004-01-22), a buglet in the GDC compiler, or a new finding that can be noted in the annals of D?

The compiler should give an error when using a file name as a module name when the file name includes non-identifier characters.