DEC variable arguments on Itanium

[Malleka Ramachandran]

I encountered a peculiar problem while porting our application to Itanium, regarding the handling of variable arguments.
We have macros defined as shown in the attached reproducer.
Variable arguments are used to trim the string in different forms, such as removing leading/trailing spaces.
What I notice is that the behavior of this program is different on the test drive Itanium box which runs 8.2-1 and on our new Itanium box 8.2. On my 8.2 system, the trim function does not work. I have shown the results in both cases below. I don't understand why the OS version should matter. I would appreciate if someone coule throw some light on this.

$ cc/ver
HP C V7.2-001 on OpenVMS IA64 V8.2-1
$ r test1/nodeb
Before calling trim: 1111111111
After calling trim: 111
Length after calling trim: 3
$ r TEST1_V82.EXE/nodeb ----> executable copied over from my machine
Before calling trim: 1111111111
After calling trim: 111
Length after calling trim: 10


On my machine:
$ cc/ver
HP C V7.2-001 on OpenVMS IA64 V8.2
$ r test1/nodeb
Before calling trim: 1111111111
After calling trim: 111
Length after calling trim: 10

[John Gillings]

Malleka,

Might sound like a dumb answer... but without any investigation, it seems that V8.2-1 is giving the "correct" answer (or, at least, expected one), V8.2 is not. Maybe V8.2-1 fixes a bug in V8.2?

Is there any particular reason you can't upgrade to V8.2-1?

[John Gillings]

Malleka,

>I don't understand why the OS version
>should matter.

Sorry, maybe I didn't understand your question... Is it "why does the copied image behave correctly on V8.2-1 and not on V8.2?"

It's all to do with OpenVMS shareable images. Instead of copying run-time-library routines into your executable image at link time, the OpenVMS linker places references to shareable images, which will be found and activated at run time. As well as saving space, this also means your program can benefit from improvements or corrections in run-time-libraries without having to recompile or relink.

In this case it sounds like there may have been a problem in the V8.2 trim routine, somewhere inside the C runtime library (DECC$SHR.EXE).

Regardless of where you built the image, when you run your program on V8.2, it uses the V8.2 trim function (incorrect?). When you run it on V8.2-1, it uses the V8.2-1 trim function which is correct.

The neat trick is OpenVMS maintains upwards compatibility with shareable images. So, if you link your program on a particular version of OpenVMS, it will run on all future versions. That's not necessarily a guarantee that it will behave exactly the same. Sometimes (as may be the case here), the later version will fix a bug. "dash" releases are counted as the same version, so your images can be freely copied between V8.2 and V8.2-1 in either direction.

OpenVMS has had shareable images since V2 (circa 1981). Other operating systems have borrowed the idea, but they don't seem to use them as much, or as effectively as OpenVMS. Windows calls them DLLs (Dynamic Link Libraries) but often seems to end up with multiple different versions with the same name. Linux has them too (not sure what they're called) but many people seem to link against object code, instead of the shared code. So, if a bug in an RTL is ever fixed, everything needs to be relinked.

[Kris Clippeleyr · Accepted solution]

Malleka,

I'm not sure why your image compiled on 8.2 works differently than the one compiled on 8.2-1; but there is definitely a bug in the example you included.
In the main function you declare an array of 10 chars (x_date), and fill it up with ten (10) characters '1'; after calling your function utl_strtrim, you print the result and call the C RTL function strlen. But where is the trailing zero that should terminate C-strings? So, either your utl_strtrim may fail or succeed, or the strlen may fail or succeed, depending on the chance that a zero is found in memory after the 'x_date' variable.

Re: John Gillings

"dash" releases are counted as the same version, so your images can be freely copied between V8.2 and V8.2-1 in either direction.

Sorry John, but this is not the case for Alpha V7.3-1 and V7.3-2; certainly not for images using executive or kernel mode data.

Regards,
Kris (aka Qkcl)

[Ian Miller.]

Kris ,"Sorry John, but this is not the case for Alpha V7.3-1 and V7.3-2; certainly not for images using executive or kernel mode data."

That backward compatability only counts for user mode apps. If you start linking with executive data structures then there is a different (but similar) version control mechanism.

Note V8.2-1 replaced V8.2 for support purposes. Support for V8.2 ends at the end of this year. V8.2-1 was a significant improvement so upgrade as soon as you can.

http://h71000.www7.hp.com/openvms/openvms_supportchart.html

The main bug with the program is the lack of null terminator on the string x_date. It may accidently work if the happens to be a zero byte after x_date in memory.

[Kris Clippeleyr]

Re: Ian


That backward compatability only counts for user mode apps. If you start linking with executive data structures then there is a different (but similar) version control mechanism.


You are correct of course. But in the old days, changes to executive cq. kernel data structures only happened between major releases (like V5 to V6); maybe occasionally between "dot"-releases; but certainly never between "dash"-releases.

Regards,
Kris (aka Qkcl)

[Ian Miller.]

Kris,
my personal theory is that V7.3-2 should have been V7.4 but was made a dash release for non-technical reasons. There where certainly more changes between V7.3-1 to V7.3-2 than is usual for a dash release.

[Malleka Ramachandran]

Thanks for all your responses, I noticed the bug in my reproducer, so I didn't get back to you sooner.