Conference decwet::visual

-o is not a known compiler switch...

With V5.0:

e:\users\roly>cl e:\users\roly\varg.cc -Fevarg.exe
Microsoft (R) & Digital (TM) AXP C/C++ Optimizing Compiler Version 11.01.7057
Copyright (C) Microsoft Corp 1984-1997.
Copyright (C) Digital Equipment Corporation 1992-1997.
All rights reserved.

Command line warning D4024 : unrecognized source file type
		'e:\users\roly\varg.cc', object file assumed
Microsoft (R) 32-Bit Executable Linker Version 5.01.7076
Copyright (C) Microsoft Corp 1992-1997. All rights reserved.

/debug:none
/out:varg.exe
e:\users\roly\varg.cc
e:\users\roly\varg.cc : fatal error LNK1136: invalid or corrupt file

e:\users\roly>cl -Tc e:\users\roly\varg.cc -Fevarg.exe
Microsoft (R) & Digital (TM) AXP C/C++ Optimizing Compiler Version 11.01.7057
Copyright (C) Microsoft Corp 1984-1997.
Copyright (C) Digital Equipment Corporation 1992-1997.
All rights reserved.

varg.cc
e:\users\roly\varg.cc(6) : error C2802: Second argument of va_start must be
		a simple parameter

e:\users\roly>cl -Tp e:\users\roly\varg.cc -Fevarg.exe
Microsoft (R) & Digital (TM) AXP C/C++ Optimizing Compiler Version
11.01.7057
Copyright (C) Microsoft Corp 1984-1997.
Copyright (C) Digital Equipment Corporation 1992-1997.
All rights reserved.

varg.cc
e:\users\roly\varg.cc(6) : error C2802: Second argument of va_start must be
		a simple parameter

e:\users\roly>type varg.cc
#include <stdarg.h>

int main() {
    va_list pvar;
    char *parm;
    va_start(pvar, parm);
    return (0);
}

With the program corrected as follows:

e:\users\roly>type e:\users\roly\varg.cc
#include <stdarg.h>

int main(int argc) {
    va_list pvar;
    va_start(pvar, argc);
    return (0);
}

Both cases compile and link without complaint (on VC5.0).
I get similar behavior with compilers as old as 10.01.AAa.
Therefore, it looks like the report is garbled and you need
to ask Computervision for a better bug report.

    CV is able to use the -o switch because they have Nutcracker installed
    and issue the compile command from a korn shell window.
    
    I have VC++ v4.1 and Nutcracker v1.6B on my NT 4.0 system (same
    environment as CV) and I am able to reproduce the problem.  I also
    still see the error when modifying the test case as suggested in note
    .1
    
    Karen

Karen,

The test case reduces to:

typedef struct {
  char *a0;
  signed int offset;
} va_list;

extern void __builtin_va_start (va_list, ...);

int main(int argc)
{
  va_list pvar;
  __builtin_va_start((pvar), (argc), 1);
  return 0;
}

This shows the error when compiled as C++ because none of three things
have happened.

1. #pragma intrinsic (__builtin_va_start) is omitted from the header.
   While not strictly necessary,
   this would point out (at least with the V5.0 compiler)
   that there's no extern "C" linkage for __builtin_va_start.

2. With C++ __builtin_va_start should have an extern "C" linkage.

3. __builtin_va_start is expected to return a void *.  V5.0 complains
   about that...

What's happening is that C++ mangles in type info into a new function name.
Then that seems to fall through the intrinsic processing without diagnosis.
The ordinary function (with mangled name) is of course not found in the
usual libraries & creates a link error.

I'd suggest that the Datafocus change their version of stdarg.h.
I've made the changes in the copy you forwarded.
ComputerVision could use this modified copy to solve their problem.

[Elided copyright notice.
I won't complain about their copying us not quite well enough.]

.
.
.

#if !defined(__STDARG_H__)

# define __STDARG_H__

#ifdef __cplusplus
extern "C" {
#endif

[...   stuff   ...]

# elif defined(_ALPHA_)
#  if defined(_CFRONT)
    extern void __builtin_va_start (va_list, ...);
#   define __builtin_isfloat(__a) __builtin_alignof(__a)
#  else
    extern void * __builtin_va_start (va_list, ...);
#   pragma intrinsic (__builtin_va_start)
#  endif

[...  other stuff   ...]

#ifdef __cplusplus
}
#endif

#endif /* !defined(__STDARG_H__) */