External Linkage in dpANS C

Paul Jackson paul at hcr.UUCP
Fri Jan 6 02:16:25 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?
Yes, in that a strictly conforming program cannot rely on better linker
and/or assembler behaviour.
>2. Is six significant monocase characters the *minimal implementation*,
>   or *required*?
Minimal.  NOT NOT NOT NOT required.  An implementation also does NOT have to
warn you if you exceed this limit (although some probably will).
>3. If required, why should a case sensitive language like C
>   use a case insensitive linker?
>4. If required, why should I damage my flexnames linker?
>5. If required, why should anybody want to use such a brain damaged
>   implementation of C?
>5. If required, how can only 6 significant characters be portable?
>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?
Although not required, the answer is simple.  Some companies with a large
C base claim that they cannot update their assembler/linker.  This, in
my opinion, constitutes the biggest kludge in the standard AND is the one
place where politics really got the best of the committee.  Note that others
would disagree with this statement.
>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, most of us realize that these programs will break.  Note that once again
this is a case of the committee acknowledging existing practice.  These programs
will ALREADY break if moved to the appropriate systems.  To that extent they
are not currently portable.  At least now everybody knows that these are the
limits one can use portably, and maybe you'll be able to get warning messages
from your favourite compiler (or lint).  In my personal opinion this was a
clear and substantial flaw in existing practice and should have been rectified,
but IT WAS existing practice.
>8. In general, aaaarrrrggghhh!
>	     James Buster



More information about the Comp.std.c mailing list