From J.Reid@letterbox.rl.ac.uk  Tue Apr 16 14:47:38 1996
Received: from letterbox.rl.ac.uk (letterbox.rl.ac.uk [130.246.8.100]) by dkuug.dk (8.6.12/8.6.12) with SMTP id OAA02466 for <sc22wg5@dkuug.dk>; Tue, 16 Apr 1996 14:47:34 +0200
Received: from jkr.cc.rl.ac.uk by letterbox.rl.ac.uk with SMTP (PP) 
          id <sg.06395-0@letterbox.rl.ac.uk>; Tue, 16 Apr 1996 13:47:04 +0100
Received: by jkr.cc.rl.ac.uk (4.1/SMI-4.1) id AA01363;
          Tue, 16 Apr 96 13:48:25 BST
Date: Tue, 16 Apr 96 13:48:25 BST
From: jkr@letterbox.rl.ac.uk (John Reid)
Message-Id: <9604161248.AA01363@jkr.cc.rl.ac.uk>
To: hennecke@rz.uni-karlsruhe.de
Subject: Re: (SC22WG5.1064) TR-C straw vote on extern C data
Cc: sc22wg5@dkuug.dk


  
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Straw vote: Treatment of C extern data objects in the TR on Interoperability 

I would prefer

  +---+
  |   |  to define a COMMON based method to access global C data objects.
  +---+
  | x |  to define a MODULE-variable based method to access global C data.
  +---+
  |   |  NOT to define facilities to access global C data objects in the TR.
  +---+

  Signed: John Reid 

Please return to hennecke@rz.uni-karlsruhe.de, if possible until 19-Apr-96.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx



Comments: I think there must be a restriction that only one module binds
to any particular C object. You could require that if a module has such
a binding, all objects in the module do. You could even require that
all such bindings reside in a single module.