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