local extern : MS vs. the world

[Tim Olson]

In article <207600006 at s.cs.uiuc.edu> carroll at s.cs.uiuc.edu writes:
| 
| Small note - MS C actually found a bug that a number of other compilers
| didn't. In porting code from UNIX to my AT, the compiler choked on code
| that compiled fine on UNIX. The problem was that it had declared
| 	extern long int mem_size
| inside several functions, but used it in a function in which it had not
| been declared. We had previously compiled this on Sun3.4, 4.3BSD on RT's,
| SysV on 3b2's and 3b20's, and a Sequent. Not one of these caught the error.
| Apparently they take 'extern' declarations to be global to the file, even
| if the declaration is local to a function. I agree with MS on this one -
| local 'extern' declarations *should* be local. Any comments?

K&R is very vague on this subject.  Section 11.1 says

	"Because all references to the same external identifier refer to
	the same object... the compiler checks all declarations of the
	same external identifier for compatibility; in effect their
	scope is increased to the whole file in which they appear."

But the X3J11 Rationale document says:

	"One source of dispute was whether identifiers with external
	linkage should have file scope even when introduced within a
	block.  The Base Document is vague on this point, and has been
	interpreted differently by different implementations... While it
	was generally agreed that it is poor practice to take advantage
	of an external declaration once it had gone out of scope, some
	argued that a translator had to remember the declaration for
	checking, anyway, so why not acknowledge this?  The compromise
	adopted was to decree essentially that block scope rules apply,
	but that a conforming implememntation need not diagnose a
	failure to redeclare an external identifier that had gone out of
	scope (undefined behavior)."

	-- Tim Olson
	Advanced Micro Devices
	(tim at crackle.amd.com)