Operating System - OpenVMS
1748067 Members
5666 Online
108758 Solutions
New Discussion юеВ

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);
}

Hoff
Honored Contributor

Re: Suppress the PTRMISMATCH error for particular C data structures

>... given the fact that dsc$descriptor_s, dsc$descriptor_d and dsc$descriptor have the same layout...

If you're uniformly using traditional and continuous and ASCII text strings, yes.

Caveat: the first eight bytes of the 32-bit flavors do use similar structure, but the remainder of the 32- and 64-bit structures do vary among flavors, and the underlying descriptors can be very different even within the various descriptors implementing 32- and 64-bit addressing.

This is a corner case in native C code, but (particularly when working in mixed-language environments) there are VMS compilers that will use a variety of these different descriptors.

This while area of C gets even more involved when you need to move off of the ASCII encoding scheme, too; when you start working with unicode.
WW304289
Frequent Advisor

Re: Suppress the PTRMISMATCH error for particular C data structures

I stand by my assertion that structures
dsc$descriptor_s, dsc$descriptor_d and dsc$descriptor, as declared in , have the same layout :-)

I realize that the *processing* may depend on the type of the structure. Apparently, this is not the issue in this thread. In general, a function accepting a pointer to dsc$descriptor can determine what structure was passed, based on values of dsc$b_dtype and dsc$b_class, and do the processing accordingly.

My point is that making the _s and _d structures inherit from dsc$descriptor does not preclude type-dependent processing by a function accepting a pointer to the base class. All inheritance does is makes it possible to have a single function for processing both _s and _d flavors (possibly, in a flavor-dependent fashion).

Thanks,
-Boris
Jeremy Begg
Trusted Contributor

Re: Suppress the PTRMISMATCH error for particular C data structures

Thanks for all your comments.

I think that in this case the simplest thing will be to declare all my strings as 'struct dsc$descriptor' and initialise them with either DSC$K_CLASS_S or DSC$K_CLASS_D as appropriate.

(No doubt I'll end up with #define macros here.)

Regards,
Jeremy Begg
John McL
Trusted Contributor

Re: Suppress the PTRMISMATCH error for particular C data structures

1. You've given no indication of the extent of the code (10 source code files? 100? 1000?).

2. To what extent are you able to edit these files? (e.g. are they third party or used successfully in current form by other people)

3. I also get the impression that you are compiling it using the "+" rather than "," syntax, which means that you are creating a single composite file.

1 & 2 relate to the magnitude of the task of modifying the files, which I would consider doing by using $ SEARCH to identify the variables causing PTRMISMATCH and again to determine how they were defined. That wousl give you the line numbers, so it's just a matter of a command file for an editor (I'd use maybe EDT or SUMSLP) and bingo the files are changed.

3 relates to whether it is possible to compile using "," which means that you might use a .h file that contains a "special" prototype(s) for the function call(s) that you are doing.