External Linkage in dpANS C

Doug Gwyn gwyn at smoke.BRL.MIL
Wed Jan 4 18:09:19 AEST 1989


In article <1339 at vsi1.COM> bitbug at vicom.COM (James Buster) writes:
>I saw mentioned in passing in one of these newsgroups (comp.std.c, comp.lang.c)
>that a variable with external linkage in dpANS C is resolved with 6 significant
>characters and no case sensitivity. I have some questions regarding this:
>1. Is this true?

Only for a few implementations.  Most will do considerably better.

>2. Is six significant monocase characters the *minimal implementation*,
>   or *required*?

Valid C external object/function identifiers that differ in their
first 6 characters other than in case must be treated as distinct.

>3. If required, why should a case sensitive language like C
>   use a case insensitive linker?

Compiler implementors don't always have control over the linker.
Many older linkers provided only what Fortran required.  Even
the PDP-11 UNIX linker had short externs (7 C source characters),
although no case folding.

>4. If required, why should I damage my flexnames linker?

Flexnames linkers are permitted.

>5. If required, why should anybody want to use such a brain damaged
>   implementation of C?

Would you rather use Fortran or Cobol?

>5. If required, how can only 6 significant characters be portable?

Portable programs should not rely on more than that.

>6. If required, why should companies with ancient linker technology
>   force me to use such ancient technology, or why can't they use 80s
>   linker technology?

It's not necessarily the compiler vendors who are responsible
for the restrictions.  Some old operating systems are too hard
(read: traumatic) to change, and until there are enough "modern"
users of those systems, the operating system vendor cannot
justify making the effort.  To do so simply to advertise
conformance to the C standard would not be considered good
enough reason, and requiring more in the standard would simply
result in fewer conforming implementations -- not better linkers.
That would be a disservice to C programmers.

>7. I presume I don't have to explain the number of programs
>   that would break because of this behavior (in particular,
>   the external identifiers _printw and _printf conflict).
>   Also, creating a function Write to interface to the system
>   write function (along with some extra stuff) is relatively
>   common practice.

No doubt about it, some programmers have been blissfully
unaware of the realities of portable programming.  There
is no change in this area due to the proposed C standard.

>8. In general, aaaarrrrggghhh!

Complain to your linker vendor if you run into this problem.
I wish you luck.



More information about the Comp.std.c mailing list