Xref: utzoo gnu.gcc:257 comp.os.vms:12520 comp.lang.c:16859
Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!mailrus!purdue!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: gnu.gcc,comp.os.vms,comp.lang.c
Subject: Re: Problems with GCC and/or VAX LINK
Keywords: globalref, extern, quotation marks
Message-ID: <9835@smoke.BRL.MIL>
Date: 10 Mar 89 19:19:14 GMT
References: <1680@levels.sait.edu.au>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 30

In article <1680@levels.sait.edu.au> ccdn@levels.sait.edu.au (DAVID NEWALL) writes:
-1.  GCC doesn't allow mismatched quotation marks.  For example:
-        /* this isn't going to work */
-    I've seen arguments over this behaviour before ...

I don't see any grounds for argument.  C has always permitted arbitrary
text in a comment, terminated when "*/" first occurs.  Syntax checking
of the contents of a comment is simply wrong.

-3.  My investigations into "globalref" high-lighted a problem with either
-    the VMS linker, or with both GCC and VAX C.  Essentialy, I can compile,
-    link and execute the following program:
-        extern v1;
-        int v2;
-        main() {
-                printf("&v1=%d\n&v2=%d\n", &v1, &v2);
-                exit(1);
-        }
-    Compiling with GCC, I get &v1 == &v2.  Compiling with VAX C I get
-    &v1 + 4 == &v2.  In either case, I think it's wrong.  I think that
-    I should get a linker error complaining about an undefined external
-    variable (v1).

Technically that's correct.  No storage has been allocated for `v1'.
A common extension found in many C implementations (especially on UNIX)
is to treat "extern" in such a context like Fortran COMMON, allocating
at link time the largest storage thus referenced, if no explicit
storage definition has been provided.  It sounds like VAX C follows that
COMMON model.  I don't know of any way that the reported GCC behavior
could be considered correct.