- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Suppress the PTRMISMATCH error for particular C da...
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-13-2010 09:31 PM
тАО12-13-2010 09:31 PM
Suppress the PTRMISMATCH error for particular C data structures
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-13-2010 10:04 PM
тАО12-13-2010 10:04 PM
Re: Suppress the PTRMISMATCH error for particular C data structures
too much work?
> Or, can I declare [...]
"void *"?
(Where "either variant" means "any old thing
at all".)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-13-2010 10:08 PM
тАО12-13-2010 10:08 PM
Re: Suppress the PTRMISMATCH error for particular C data structures
I don't want to declare them as 'void *' precisely because that disables type checking.
Thanks anyway.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-13-2010 11:34 PM
тАО12-13-2010 11:34 PM
Re: Suppress the PTRMISMATCH error for particular C data structures
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-14-2010 07:25 AM
тАО12-14-2010 07:25 AM
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.
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.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-14-2010 07:53 AM
тАО12-14-2010 07:53 AM
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
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);
}
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-14-2010 08:07 AM
тАО12-14-2010 08:07 AM
Re: Suppress the PTRMISMATCH error for particular C data structures
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-14-2010 09:15 AM
тАО12-14-2010 09:15 AM
Re: Suppress the PTRMISMATCH error for particular C data structures
dsc$descriptor_s, dsc$descriptor_d and dsc$descriptor, as declared in
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-14-2010 04:56 PM
тАО12-14-2010 04:56 PM
Re: Suppress the PTRMISMATCH error for particular C data structures
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-15-2010 01:41 PM
тАО12-15-2010 01:41 PM
Re: Suppress the PTRMISMATCH error for particular C data structures
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.