Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Suppress the PTRMISMATCH error for particular C data structures

 
Jeremy Begg
Trusted Contributor

Suppress the PTRMISMATCH error for particular C data structures

Hi,

This question is to do with suppressing C compiler messages, and using /WARN=DISABLE=... is more than I want.

I have some C modules which in the past were compiled with /STANDARD=VAXC. I've been recompiling them without the /STANDARD=VAXC qualifier (in the possibly mistaken belief that the qualifier is now considered "bad practice").

The main outcome of this is a lot of PTRMISTMATCH error messages. Many of these are produced when a function declaration specifies

int my_function (struct dsc$descriptor *str)

but the actual parameter at runtime is some varition on the string descriptor type, e.g. struct dsc$descriptor_s or struct dsc$descriptor_d. (The function doesn't modify the string, so it doesn't really care if it's _s or _d.)

Is there some way to tell the C compiler to treat 'struct dsc$descriptor', 'struct dsc$descriptor_d' and 'struct dsc$descriptor_s' as equivalent, so that it doesn't issue PTRMISMATCH for those data types?

Or, can I declare my formal string parameter another way so that the compiler will accept either variant on the actual parameter, without complaint?

Thanks,
Jeremy Begg
10 REPLIES 10
Steven Schweda
Honored Contributor

Re: Suppress the PTRMISMATCH error for particular C data structures

A type cast on each function invocation is
too much work?

> Or, can I declare [...]

"void *"?

(Where "either variant" means "any old thing
at all".)
Jeremy Begg
Trusted Contributor

Re: Suppress the PTRMISMATCH error for particular C data structures

I haven't written off type casts as an option, but there will be quite a few of them and they're rather ugly.

I don't want to declare them as 'void *' precisely because that disables type checking.

Thanks anyway.
John McL
Trusted Contributor

Re: Suppress the PTRMISMATCH error for particular C data structures

How about a #define that maps the different types to be just one standard fom?
Hoff
Honored Contributor

Re: Suppress the PTRMISMATCH error for particular C data structures

No Good Answer.

HP C doesn't have any sort of inheritance among similar data types as can be provided within some variants of C and in other languages, so you're left with a variety of bad solutions.

Void casting, or assignment to the correct type via a macro or explicit statements, or use of the expected type or parallel function definitions (mumble_d and mumble_s or whatever) are the common solutions here.

The macro can be inline or can be a call to a function that's inline, and basically performs checks and a void cast.

The brute-force solution can be to use pragmas around the declarations of the most pernicious and most endemic of these declarations off in your header files, but that's not without risk. To save the settings, disable the mismatch errors, then restore the settings.

In years past and when I've gone in to swamp-drain old C code, the use of SDL has been a commonplace solution; to move the declarations and such into SDL and generate the headers from there. This if you're planning mixed environments, but it's not a particularly good solution for an all-C environment, and where you're not looking to solidify your API declarations.

There are some run-time checks that can be added either within the call or probably more commonly within the called routine that allow you to check the data type. This gets ugly, but it allows you to specify void in the call and to catch the expectations at run-time.

The bazooka solution of a preprocessor define to change all the types to the same type is usually hazardous; you can't change all the declarations in the compilation scope without also altering those that are explicitly written as intended; when the _s or _d is the correct type.

And yes, use of the old VAX C /STANDARD=VAXC settings is arguably bad practice. That's the bad-old days of C, and removing that is a good way to locate latent errors.

If you go after this stuff wholesale, then look to enable at least QUESTCODE, and I'd probably look to use (what parts of) C99 are available in current compilers.

Compiler Enhancement: It'd be nice if the HP C compiler had better support for strings and particularly for string descriptors as arguments but (the more I work with other languages and in variants of C) the effort required to work with strings in traditional C becomes far more obvious. Some sort of a dsc$descriptor_any declaration that the compiler would honor in declarations. (But what plans there might be for new compilers or for compiler updates, you'll have to ask HP.)
WW304289
Frequent Advisor

Re: Suppress the PTRMISMATCH error for particular C data structures

"
HP C doesn't have any sort of inheritance among similar data types as can be provided within some variants of C and in other languages, so you're left with a variety of bad solutions.
"

Yes, no good answer for C. In C++, given the fact that dsc$descriptor_s, dsc$descriptor_d and dsc$descriptor have the same layout, the _s and _d structures could be derived from dsc$descriptor, as in example below. Would be a nice enhancement in for compilations with C++, a step towards "any string".

Thanks,
-Boris

struct dsc$descriptor
{
unsigned short dsc$w_length;
unsigned char dsc$b_dtype;
unsigned char dsc$b_class;
char *dsc$a_pointer;
};

struct dsc$descriptor_s : dsc$descriptor {};
struct dsc$descriptor_d : dsc$descriptor {};

void my_function(struct dsc$descriptor* str);

void caller() {
struct dsc$descriptor_s s;
struct dsc$descriptor_s d;
my_function(&s);
my_function(&d);
}