|Posted by Jonathan Leffler||PermalinkReply|
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
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):
private final char rcs = "@(#)$Id$";
int main(char argv)
for (i = 1; i < argv.length; i++)
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: email@example.com, firstname.lastname@example.org
Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/