%CC-W-NOTCOMPAT

[R SAMANTARAY]

We are migrating from OpenVMS/VAX to OpenVMS/ITNIUM. In an application index is declared as integer variable. During compilation it is giving an error

“ %CC-W-NOTCOMPAT, In this declaration, the type of "index" is not compatible with the type of a previous declaration of "index" at line number 277 in file SYS$COMMON:[SYSLIB]DECC$RTLDEF.TLB;1 (text module STRING) “

Can you suggest how to resolve this problem without changing the name index.

[Robert Gezelter]

R SAMANTARAY,

It would be useful to see the actual definition of the variable. It would also be helpful to know the version numbers of the OS and compiler on each architecture.

As a general principal, the C specification and the C compiler have become more strict about language issues over the years. As a guess, I would say that is what happened.

Extracting the relevant module from DECC$RTLDEF.TLB and looking at the identified line is part of understanding what the problem is.

- Bob Gezelter, http://www.rlgsc.com

[Richard Whalen]

The (old) C compiler that you have been using did not have the index function, which searches for a character in a string.

http://h71000.www7.hp.com/doc/83final/5763/5763pro_042.html#index_x_1138

You might have some luck with one of the following qualifiers on your command line:

/DEFINE=_ANSI_C_SOURCE

or

/DEFINE=(__CRTL_VER=60200000)

[R SAMANTARAY]

Vax 4300 VMS 6.2 to Itanium VMS 8.3

Product Producer Units PCL Activ Version Release Termination
C HP 2 0 1 0.0 (none) (none)

[Jim_McKinney]

> You might have some luck with one of the following qualifiers on your command line

Or, to continue on the theme offered by Richard Whalen, you could change the name of that variable to something other than "index" which now belongs to C's new index() function.

[Hein van den Heuvel]

If you go to the exact source line pointed to in the error message you see:

277>> char *index(const char *, int);

This definiton will have been in effect early on.

Along with the error message you'll find
a line number (and text) in the source you are trying to compile.

Show it here?

Review that source area and, if you can, just change the definitions in the source to use somethign other than index (my_index, index_number, ...).
I'm sure there are compiler switches and conditional compiles and other trick to keep using the name 'index', but it's probably much easier for all to give in on this point.

hth,
Hein.

[Hoff]

I'm going to make a few assumptions on limited data.

The code is broken. Whomever programmed this violated ANSI/POSIX rules. What you're seeing here is a fairly common C coding error, due either to somebody creating their own version of index for an environment that doesn't have the function, or that is creating another and unrelated index function using a reserved name. (Reserved here under the rules of the C standard.)

One fix common to some Unix programmers is to try to sequence when a module is included; to play with the declaration order. That doesn't work reliable, and it'll throw errors on OpenVMS.

One usual OpenVMS workaround -- without changing the (broken) source code -- is to use /FIRST_INCLUDE and a preprocessor define to change the name of index to something else that is standards compliant.

The best fix is to use a name that complies with the C standards, and that doesn't use the name of an reserved function.

If there is a requirement to have an index function around in the code for environments that lack same, the usual fix is to have the function declared under another name and to use the preprocessor define to overmap to the local name when required. Some folks might have a module with the reserved name, but that can run afoul of compilers that check for reserved names.

There's a verbose messages option available in current C compilers. /WARNINGS=VERBOSE When enabled, this compiler option gets you more detailed error messages.

When feasible, consider trying to build C code with something akin to:

/WARNINGS=ENABLE=(LEVEL4,QUESTCODE)
/STANDARD=PORTABLE/ACCEPT=NOVAXC_KEYWORDS

and then to add additional options including VERBOSE and PORTABLE to /WARNINGS if and as needed.

In a whole chunk of the C code I've dealt with over the years, adding these compiler flags tends to show where I'll have problems when I port the code. Sometimes where I can have problems with OpenVMS upgrades, too. These compiler flags help find the weird errors earlier, and the diagnostics here tend to be better than those typical of some other common C compilers.

Stephen Hoffman
HoffmanLabs LLC