[Info-vax] C troubles: BADSTATICCVT

[Craig A. Berry]

On 2/2/18 8:48 AM, John Reagan wrote:
> 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.

Thanks! It's easy to imagine a compiler engineer thinking there was no
reason to provide a conversion of a 32-bit address to a 64-bit integer
at compile time, especially when not using 64-bit pointers.

As a workaround, I'm already having to roll my own stdint.h, so I may
have to make my own 32-bit intptr_t definition there and avoid
including inttypes.h (where intptr_t is currently defined). It's not
used in any interfaces, so I just might get away with it. Of course this
will all blow up in my face once you guys add stdint.h to the CRTL,
which I'm guessing is part of v8.5.
> 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 <snip>

Getting back to work seems like a reasonable choice. The fact that
things were done the way they were 20 years ago given the goals and
constraints of the time doesn't bother me. What bothers me is that there
should have by now been several major rethinks of how it all works but
since the Compaq era if not before the holders of the purse strings have
not wanted to make the investment.