cancel
Showing results for 
Search instead for 
Did you mean: 

DEC warnings

Malleka Ramachandran
Frequent Advisor

DEC warnings

We upgraded to OpenVMS 6.2 and DEC C 6.0 on the Alpha.
When I recompile our application, I am getting a warning about static initializers. I don't understand the meaning/implication of this. I would appreciate if someone could explain this to me.
What we have is array of structures of about 50 entries and the values of the descriptor strings are initialized in the header file.

I get the following message:
NDMEVL$T$_LINKFAILURE , NDMEVL$C$_USER_INTERFACE , ui_LinkFailure ,
..^
%CC-W-STATINITWARN, The linker will be unable to perform this static initializa
tion if the initializer is defined in a sharable image.
at line number 191 in file $1$DKB200:[NDM.3300DEV.NDM.INCLUDE]NDM$EVENT_DESCRIPTION.H;1

...

NDMEVL$T$_RUNJOBREMOTECOMPLETE , NDMEVL$C$_SESSION_REQUESTER , s♦
..^
%CC-W-STATINITWARN, The linker will be unable to perform this static initializa
tion if the initializer is defined in a sharable image.
at line number 237 in file $1$DKB200:[NDM.3300DEV.NDM.INCLUDE]NDM$EVENT_DESCRIP
TION.H;1
Fatal: Insufficient virtual memory to continue compilation.
%LIB-F-INSVIRMEM, insufficient virtual memory

I looked up the description of the warning and it says "
CC

Messages

STATINITWARN


Message The linker will be unable to perform this static
initialization if the initializer is defined in a
sharable image.

Description A static initialization will require that a link-time
constant be truncated. If the constant is resolved
in a sharable image, the linker will issue a
diagnostic and be unable to perform the
initialization. This message is output on OpenVMS
systems only.

User Action Rewrite the static initialization so that the link-time constant will not be truncated.

I would appreciate if someone could throw some light on this.

Thanks,
Malleka

16 REPLIES
Steven Schweda
Honored Contributor

Re: DEC warnings

> We upgraded to OpenVMS 6.2 and DEC C 6.0 on the Alpha.

From ...?

> %LIB-F-INSVIRMEM, insufficient virtual memory

I'd start by increasing your pagefile quota,
or whatever is causing this one.

> %CC-W-STATINITWARN [...]

Knowing nothing, I'd expect a link-time
constant to be an address of some sort, and
you might be trying to put a 64-bit value
into a 32-bit destination. Without seeing
any of the declarations, it's hard to say.
(Of course, even if I saw them all, it might
_still_ be hard for _me_ to say.)
Hein van den Heuvel
Honored Contributor

Re: DEC warnings


Hmmm, DEC C 6.0 is still pretty old.
7.1 is current and 6.5 has been available since early 2002 or so.

http://h71000.www7.hp.com/commercial/c/c_index.html


INVIRMEM is like a quota problem as replied earlier. Specifically check out the PGFLQUO value with authorize for the user running the compiler, or when logged in as that user issue "SHOW PROC/QUO" and look for "Paging file quota:"

as for the STATINITWARN... it means exactly what it says. Rules may have been tightened, old problems may now have been recognized. That is, that same code in the older version may have had the same gotcha, but the older compiler failed to warn you for it.
If you do not intent to create a shareable image then you can ignore it, but I would take it as a suggestion that there is something fishy about the variable initialization done at line 191 and 237 and try to do something about it.
If you need help on that, then you probably need to include relevant chunks of the source code, and underlying structure definitions as a text attachment to a subsequent reply.

hth,
Hein.



John Gillings
Honored Contributor

Re: DEC warnings

Malleka,

STATINITWARN means the initialisation of a variable involves the address of another variable which is not declared within the scope that the compiler can "see" at compile time. The warning is telling you that if the target variable is ultimately resolved from a shareable image, the assumptions made by the compiler may be broken, and you may get incorrect results.

For a full explanation for how to resolve this, you'd need to post a small reproducer.
A crucible of informative mistakes
Malleka Ramachandran
Frequent Advisor

Re: DEC warnings

I think I did not describe the scenario regarding the versions. What I meant by upgrade was the following scenario:

We have our application running on OpenVMS AXP 1.5, C compiler 1.3-000A.
The client has agreed to move on to higher OS versions, so as a first step we are porting the application to OpenVMS 6.2H3. We have a new Alpha box with this version, which has DEC C 6.0 installed. The warnings I mentioned above are while recompiling the application on this box.
Yes, I understand that the pgflquota could be an issue as mentioned in the replies but I would like to understand this condition so that it will be useful when we go further with more recent OS versions (and the corresponding C compiler versions).
If the DEC C version needs to be upgraded, as mentioned in one of the replies, I can work in that direction too.
Attached is the source and header files.

Thanks,
Malleka
Malleka Ramachandran
Frequent Advisor

Re: DEC warnings

I'm not sure if both files got attached to my previous message, so I'm sending the header files, just in case.
John Gillings
Honored Contributor

Re: DEC warnings

Malleka,

Sorry, I can't compile your code, way too many missing include files, and way too much code.

You should be able to cut out the definitions for ONE object that's generating this error and produce a small, self contained source module that anyone can compile. It doesn't matter if the program doesn't make sense.

So, for example, why not start with:

NDMEVL$C$_USER_INTERFACE , ui_LinkFailure ,
..^
%CC-W-STATINITWARN, The linker will be unable to perform this static initializa

Trace back all the dependent definitions and place them in a single file.
A crucible of informative mistakes
John Gillings
Honored Contributor

Re: DEC warnings

Malleka,
If you can dig out the definition of
ndm$event_description, I may be able to reproduce the symptom.
A crucible of informative mistakes
Malleka Ramachandran
Frequent Advisor

Re: DEC warnings

Sorry I could not get the header file ndm$event_description.h to get attached to my posting for some reason. I am trying to do it again. I also have modified the c source to exclude other include statements.

Thanks,
Malleka
Malleka Ramachandran
Frequent Advisor

Re: DEC warnings

I did not reaalize the header files I attached in my previous message has more includes in it. here are the the two other header files.
Malleka Ramachandran
Frequent Advisor

Re: DEC warnings

the second one...
John Gillings
Honored Contributor

Re: DEC warnings

Malleka,

OK, here's what I mean by a short reproducer!

main(){
globalvalue int X;
struct Y {unsigned short a;};
static struct Y readonly Z[]={X};
}



Your NDMEVL$* symbols, defined in NDM$EVENT_TYPE.H are all "globalvalue int". They're used to initialize elements of the array EVENT_DESCRIPTION_TABLE. Elements are of type "event_description_entry", and the initialized fields "type" and "class" are both declared as "unsigned short".

This is a type mismatch. You're trying to fit an int into a short.

If these were COMPILE TIME constants, the compiler could check that the "int" values fit into a "short" field, and warn you if there was any truncation.

Since, "globalvalue" are LINK TIME constants, it's up to the linker to do the initialization and possibly truncation of the value, again with a warning if data was lost. However, if those symbols are resolved from a shareable image, instead of an object module, then they're RUN TIME constants, and performing the correct initialization, truncation & warning is way beyond the capabilities of the image activator.

This is what the compiler is warning you about.

So, if you KNOW absolutely that these values will never exceed the size of a "short" field, then ignore the warning. If not, then you'd be better off defining the fields to be "int" instead of "short". Alternatively, you could define the symbols as "globalvalue short". It all depends on where and how the values of the symbols are defined. You should be able to determine that from the linker MAP file.

Bottom line is, you need to resolve the type mismatch to make the compiler happy.

From the look of the code, I'd say changing "type" and "class" to "unsigned int" should be safe. It will make the table slightly bigger, but memory is cheap! The only potential problem is if there is code that assumes the fields are "short" (but, judging by the coding style, the programmer knew exactly what they were doing, and I'd guess there are no such dependencies).

(and if that effort isn't worth a few points, I don't know what is! :-)
A crucible of informative mistakes
Malleka Ramachandran
Frequent Advisor

Re: DEC warnings

Thanks, John, it worked.
Arch_Muthiah
Honored Contributor

Re: DEC warnings

Mallega,
your profile shows, you assigned points to only one out of 15 responses.

> I have assigned points to 1 of 15
> responses to my questions.

Please try to spend time to assign the points.


Archunan
Regards
Archie
Malleka Ramachandran
Frequent Advisor

Re: DEC warnings

I think this software does not work as expected. Yesterday I assigned points to all responses to DEC C warnings before I responded to John saying it works. But now it shows all responses as unassigned. This could have happened with all previous responses too. Please let me know if someone knows how to fix this. I no longer see a drop down list so I can go ahead and assign points again.

Thanks,
Malleka
Kris Clippeleyr
Honored Contributor

Re: DEC warnings

Malleka,

You seem to have 2 profiles:

This is the one you used to start this thread:

http://forums1.itrc.hp.com/service/forums/publicProfile.do?userId=CA1290226&forumId=1

This one, you used in your last reply:

http://forums1.itrc.hp.com/service/forums/publicProfile.do?userId=CA1341125&forumId=1

You have to log in using the CA1230226 profile in order to be able to assign points.

Regards,
Kris (aka Qkcl)
I'm gonna hit the highway like a battering ram on a silver-black phantom bike...
Jan van den Ende
Honored Contributor

Re: DEC warnings

Yes,

Not only do you have two IDs, but those also have different names: CA1230226 is "Malleka",
where CA1341125 is "Malleka Ramachandran"

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.