topic Re: DEC warnings in Operating System - OpenVMS

DEC warnings

Malleka Ramachandran — Fri, 18 Nov 2005 11:30:05 GMT

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

Re: DEC warnings

Steven Schweda — Fri, 18 Nov 2005 17:07:28 GMT

> 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.)

Re: DEC warnings

Hein van den Heuvel — Sun, 20 Nov 2005 08:55:22 GMT

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.

Re: DEC warnings

John Gillings — Sun, 20 Nov 2005 15:58:57 GMT

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.

Re: DEC warnings

Malleka Ramachandran — Mon, 28 Nov 2005 13:05:51 GMT

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

Re: DEC warnings

Malleka Ramachandran — Mon, 28 Nov 2005 13:08:49 GMT

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

Re: DEC warnings

John Gillings — Mon, 28 Nov 2005 20:39:24 GMT

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.

Re: DEC warnings

John Gillings — Mon, 28 Nov 2005 20:46:19 GMT

Malleka,
If you can dig out the definition of
ndm$event_description, I may be able to reproduce the symptom.

Re: DEC warnings

Malleka Ramachandran — Tue, 29 Nov 2005 15:21:28 GMT

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

Re: DEC warnings

Malleka Ramachandran — Tue, 29 Nov 2005 15:32:15 GMT

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.

Re: DEC warnings

Malleka Ramachandran — Tue, 29 Nov 2005 15:33:36 GMT

the second one...

Re: DEC warnings

John Gillings — Tue, 29 Nov 2005 16:23:11 GMT

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! :-)

Re: DEC warnings

Malleka Ramachandran — Wed, 30 Nov 2005 17:33:53 GMT

Thanks, John, it worked.

Re: DEC warnings

Arch_Muthiah — Wed, 30 Nov 2005 17:51:55 GMT

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

Re: DEC warnings

Malleka Ramachandran — Thu, 01 Dec 2005 06:54:43 GMT

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

Re: DEC warnings

Kris Clippeleyr — Thu, 01 Dec 2005 07:00:46 GMT

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)

Re: DEC warnings

Jan van den Ende — Thu, 01 Dec 2005 14:35:22 GMT

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