[Info-vax] C troubles: BADSTATICCVT

[John Reagan]

On Friday, February 2, 2018 at 9:06:41 AM UTC-5, Craig A. Berry wrote:
> On 2/2/18 7:18 AM, hb wrote:
> > On 02/02/2018 12:49 AM, Craig A. Berry wrote:
> >> $ cc static_const1
> >>
> >>      42, (intptr_t)"."
> >> ..................^
> >> %CC-E-BADSTATICCVT, In the initializer for mydata[0].nonsense, the
> >> address cannot be converted to the destination type.
> >> at line number 9 in file D0:[craig.TEST]static_const1.c;3
> >>
> >> HELP CC MESSAGES BADSTATICCVT tells me, "A static initialization tried
> >> to convert a link-time address to another type. However, the linker on
> >> this platform will not support such a conversion." And also that I
> >> should, "Rewrite the static initialization, or perform the
> >> initialization using runtime code."
> > 
> > Probably someone else can and will explain the error code (to me it
> > looks like the compiler hesitates to issue a relocation the linker can't
> > process) I only observed that without the cast, there is an additional
> > warning
> > 
> > $ cc static_const1.c/pointer=64
> > 
> >      42, "."
> > ........^
> > %CC-W-CVTDIFTYPES, In the initializer for mydata[0].nonsense, ""."" of
> > type "short pointer to char", is being converted to "__int64".
> > 
> > As a workaround, you may want to cast to int32_t. This seems to work for
> > HP C V7.3-010 on OpenVMS Alpha V8.4-2L2.
> 
> Aha. So it does. Which means this is probably yet more fallout from the
> mongrel 64-bit pointer implementation since intptr_t is 64 bits on
> non-VAX regardless of whether the pointers are 32-bit or 64-bit. So
> trying to convert a 32-bit address into a 64-bit integer is not
> something it can do at compile time.
> 
> But there must be more to the story as compiling with /POINTER_SIZE=64
> doesn't fix it.

I agree.  I've been playing with it for 30 minutes or so and have come to the same conclusion.  I suspect there is just a missing entry in some conversion table.  I can look further, but not today.

I've written several draft posts about the "whys" and "why nots" of the 32/64 bit pointer history but always deleted them and gone back to work.

If you come with me into the Tardis (don't worry, there's plenty of room) and go back in time, you'll find lots of code shared between VAX and the soon to be Alpha.  While the VMS group cloned the source pools, there is lots of code shared there as well.  There is LOTS of Macro-32 code and LOTS of BLISS-32 code.  That code is full of 32-bit descriptor, 32-bit itemlists, and shoving VAX code addresses into 32-bit locations.  While well-written BLISS might be easily transformed into BLISS-64 code, Macro-32's ability to abstract the size of things is horrible.  All those "L" letters in things like MOVL, ADDL, etc.  making the compiler turn "L" into "LL" or MOVAx now makes a 64-bit value leads down the road to madness.  Looking back, I think I want to point a finger at itemlists (and to a lesser degree descriptors).  The exposure of "address" into languages that don't have that concept ended up with %LOC into INTEGER*4's in Fortran or even worse COBOL.  The time, effort, risk, and pressure from customers to "recompile and go" lead us into the dual pointer environment.  I do remember discussing a hard split and doubling of libraries, etc. and mixed interaction (passing Fortran LUN numbers around as an example) make that solution complicated as well.  Nobody wanted to try to tackle RMS-64 (then or now).  Just think about a cluster-wide shared indexed file being read/updated from both RMS-32 and RMS-64 code stacks.  Toss in process-perm-file handling...