Path: utzoo!attcan!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!mailrus!ames!pasteur!ucbvax!VENUS.YCC.YALE.EDU!LEICHTER
From: LEICHTER@VENUS.YCC.YALE.EDU ("Jerry Leichter ", LEICHTER-JERRY@CS.YALE.EDU)
Newsgroups: comp.os.vms
Subject: re: VAX C - relative adresses?
Message-ID: <8805170934.AA05192@ucbvax.Berkeley.EDU>
Date: 15 May 88 18:59:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 46


	[In VAX C,] I would like to create a static table of address offsets
	in VAX C, like

        static <type> base
        extern <type> item1,item2,...
        static readonly int tab[size] = {&item1 - &base,&item2 - &base, ...}

	so I'd have POSITION-INDEPENDENT data only (for use in a shareable
	image)

	Now simple adresses (+- offset) are legal initializers in C, but not
	their difference, so the above program won't compile, while

        static readonly char *tab[size] = {&item1,&item2,...}

	is o.k.

	Do you know of a way to convince VAX C to do the desired
	(compile-time) initialization?

Ah, but it ISN'T a compile-time initialization:  The value of &item1-&base
isn't known to the compiler, nor can it be known until the program is linked.

This kind of initializer is certainly not allowable in standard C; many
linkers are unable to evaluate such expressions.  On an architecture with a
segmented address space, the difference between two addresses may not even be
meaningful.

The VMS Linker could, in fact, evaluate such an expression if asked to, but
VAX C doesn't provide any mechanism for this.

You can build a table like tab[] in macro.  I don't know Bliss well enough to
know if it can specify such a table; probably.  I doubt any other VMS HLL will
let you do this.

The best I can suggest is that rather than using a whole bunch of separate
variables, you use one structure with a lot of fields, one per variable.
You then end up with a table of offsets to structure fields, which it IS
possible to compute at compile time; in fact, ANSI C even provides an offsetto
built-in macro to do this.

On the other hand, once you've put everything into one structure, you may find
that you really don't need the table anyway.

							-- Jerry