64-bit compilation problem on Solaris/Intel: 7th argument not initialized

Question

I have a problem when compiling a program on a 64-bit Solaris Intel server. The problem is that when calling a function, if the 7th or next arguments are long arguments and I pass uncasted small integers values to it, the first 32-bit of my values are uninitialized.
I have isolated the problem in the following source code.
#include <stdio.h>
#include <strings.h>
void fnc1(a,b,c,d,e,f,g,h)
long a,b,c,d,e,f,g,h;
printf("%ld,%ld,%ld,%ld,%ld,%ld,%ld,%ld\n", a,b,c,d,e,f,g,h);
void main()
fnc1(0x10101010deadbeef,0x20202020deadbeef,
     0x30303030deadbeef,0x40404040deadbeef,
     0x50505050deadbeef,0x60606060deadbeef,
     0x70707070deadbeef,0x80808080deadbeef);
fnc1(1,2,3,4,5,6,7,8);
}I compile it using the following command:
cc src1.c -g $* -m64 -o prog1.exeWhen I run the resulting .exe, I get the following result:
1157442768875667183,2314885534015405807,3472328299155144431,4629771064294883055,5787213829434621679,6944656594574360303,8102099359714098927,-9187201948855714065
1,2,3,4,5,6,8102099355978170375,-9187201952591642616The problem is that the first 32 bits of my 7th and 8th arguments are not initialized when the function is called.
I know that in the following cases, I do not have the problem:
- if I cast the arguments;
- on other platforms (AIX, SunOs/Sparc, HPUX) or if I compile in 32-bit;
- if I use optimization (-xO1 to -xO5) ;
- if I prototype my function at the beginning of my source (void fnc1(long a,long b,long c,long d,long e,long f,long g,long h););
I have over 1,000,000 lines of existing code to support. I am afraid using optimization would have other impacts and for now, I cast the arguments as problems are reported. Would there be a better way to handle this? By using a compiler switch?
Thanks in advance.

Answer 1

Tom.Truscott wrote:
clamage45 wrote:
But if you are passing to an ellipsis, you either cast actual arguments to the type the function expects, or the function extracts the default promoted type. Such code always works ...Yes, and developers should attempt to accomplish just that. Alas this is very difficult to ensure, particularly given the lack of a run-time type checking mechanism.In theory, proper use of the ellipsis function would be documented, and programmers would read and follow the documentation. In practice, some programmers don't read the instructions, or forget them, or someone ill-advisedly changes the way the function works so that existing calls stop working. Variable-argument functions are a fragile mechanism. (I program almost exclusively in C++, which has combinations of features such that variable-argument functions are rarely, if ever, needed.)
Can one even assume that the value of the NULL macro is correct? Never, because the C standard allows a variety of definitions for NULL, and implementations vary. Passing NULL to an ellipsis is a recipe for failure. Don't do it.
>
Suppose you have function FI with an ellipsis that expects to get int arguments, and another FL that expects to get long arguments. When you port the code to a 64-bit environment, function FL fails. If you use the -signext option, function FI will fail.Ah, but for us FL never fails, since the compilers always widen the arguments. I fail to see the circumstance in which widening would cause FI to fail, could you please give a more specific example?
void FI(int count, ...)
    va_list va;
    va_start(va, count);
    int t;
    while( --count >= 0) {
       t = va_arg(va, int);
       do_something(t);
}Function FI expects to extract 32-bit int arguments. If compiled with -signext, the calling function will pass 64-bit arguments. Perhaps the -signext option also causes the 32-bit extraction to be changed to a 64-bit extraction. I have no personal experience with the option, and I'm not in a position where I can experiment right now.