External Linkage in dpANS C

[William E. Davidsen Jr]

  Since I was still on the committee when this came up (the first time)
I can state that this was a political decision rather than a technical
decision. In spite of that I guess it's correct at this time.

  There are several companies which have linkers with the limitations
you so justly criticized. There was a feeling (there may have been an
outright statement) that these companies would not produce a vendor
supplied C compiler if their existing linker couldn't be conforming, and
that they wouldn't use C as a library implementation language if they
couldn't link it with existing languages.

  Because these companies have a financial stake in a standard which
they could offer, it was felt that rather than chance non-support or
even opposition for this version of the standard, it was a necessary
compromise.

  Two companies which have limited linkers in at least some of their
operating systems are Honeywell and IBM.

  This standard is supposed to "codify existing practice," and in many
cases that implies compromise to avoid breaking existing
implementations. Hopefully there will be a new standards committee in a
few years with a goal of producing a new version with significant
enhancements and extensions, and allowed to make changes needed for a
more consistant language. I *don't* mean "codify C++" which is a
language in its own right.

  In spite of my criticism of the committee at times I think they have
done a fine job within the limitations of compromise, and I am happy
that I was able to participate for a few years.
-- 
	bill davidsen		(wedu at ge-crd.arpa)
  {uunet | philabs}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me