no excuse for short identifiers in the standard

[David Yost]

There have been many, many wonderful arguments for
standard long global identifiers on net.lang.c, more than
anything I could ever think of.

The only important argument against long externals has
been that on some systems it is impossible to build a
compatible implementation.  Nonsense.

To C implementors on those unfortunate systems that
have object module formats with monocase identifiers or
identifiers limited to 2, 5, 6, 8, or whatever, follow
these simple steps:

1.  Design a new object module format that conforms to
    the C standard.  Implement your C compiler to
    output this format (preferably after going through
    an assembler, which you should also provide).

2.  If it is impossible to design the C object format
    so that it can be executed by the operating
    system, then provide a translator from C object
    format to executable format or provide a linker
    option for making an executable.  Be sure you
    provide a way to output the executable with a
    complete symbol table, so a reasonable debugger
    can be implemented.

3.  If there is a need to link in modules produced by
    some other language, such as fortran or macro,
    then provide an object translator from that format
    to your C object format.  If the identifiers in
    that language are monocase, then map them to lower
    case in the C format.  This conversion program
    should provide for an optional lookup table
    mapping old names to new names.

If that's too much work, then please don't implement
a C compiler at all.

Since many new linkers and assemblers are going to have
to be built, I suggest that an ANSI C assembler/linker
standards committee should be formed to try to keep
this part of the C compiler environment standard.
One of the important issues here is that provision
should be made for symbol table information to support
source-level debuggers.  And please, let's not standardize
on the unix linker.  It's too simple-minded.

--dave yost