- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: HP C V7.3-009 on OpenVMS Alpha V7.3-2, spuriou...
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
тАО09-08-2009 11:01 AM
тАО09-08-2009 11:01 AM
HP C V7.3-009 on OpenVMS Alpha V7.3-2, spurious %CC-E-BADCONDIT?
HP C V7.3-009 on OpenVMS Alpha V7.3-2
alp $ cc badcondit.c
= opt_ignore_case ? strcasecmp : strcmp;
..............^
%CC-E-BADCONDIT, In the initializer for cmp, a common type could not be determin
ed for the 2nd and 3rd operands ("strcasecmp" and "strcmp") of a conditional ope
rator.
at line number 8 in file ALP$DKA0:[SMS]BADCONDIT.C;1
alp $ type badcondit.c
#include
int main( void)
{
int opt_ignore_case;
int (*cmp) (const char *, const char *)
= opt_ignore_case ? strcasecmp : strcmp;
}
There seems to me to be no significant
difference between the declarations (in
[...]
int strcmp (const char *__s1, const char *__s2);
[...]
int strcasecmp(const char *, const char *);
[...]
No such problem was seen in a different
(newer?) environment:
it $ cc /version
HP C V7.3-018 on OpenVMS IA64 V8.3-1H1
it $ cc badcondit.c
it $
Known problem or not?
Any patch/product kit available to a
non-paying peon?
An annoying type cast seems to work around the
problem, but it's not my code, so adding code
clutter is not the ideal solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-08-2009 11:57 AM
тАО09-08-2009 11:57 AM
Re: HP C V7.3-009 on OpenVMS Alpha V7.3-2, spurious %CC-E-BADCONDIT?
If that's the entire C code here (and I'm guessing not), then that opt_ignore_case seems odd.
Or use the duct tape of C; lob some void-casts at the code.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-08-2009 12:45 PM
тАО09-08-2009 12:45 PM
Re: HP C V7.3-009 on OpenVMS Alpha V7.3-2, spurious %CC-E-BADCONDIT?
Hey. Fingers broken? Sold/junked your last
Alpha?
[...]
Command Line
------- ----
CC badcondit.c/LIST/SHOW=(ALL,NOMESSAGE)
[...]
I1 708 int strcmp (const char *__s1, const char *__s2);
[...]
I1 817 int strcasecmp(const char *, const char *);
[...]
I1 937 # pragma __use_linkage __str_link2 (strcmp)
[...]
1 1003 int (*cmp) (const char *, const char *)
1 1004 = opt_ignore_case ? strcasecmp : strcmp;
..............1
%CC-E-BADCONDIT, (1) In the initializer for
cmp, a common type could not be determined
for the 2nd and 3rd operands ("strcasecmp"
and "strcmp") of a conditional operator.
[...]
> If that's the entire C code here (and I'm
> guessing not), then that opt_ignore_case
> seems odd.
It's not the whole original source file, just
the troublesome part. In real life,
"opt_ignore_case" is "opt.ignore_case", and
it's set to something. This is a simplified
test case, but the BADCONDIT complaint is
the same.
On the IA64 system, I see:
[...]
I1 X 913 #if defined(__ALPHA) && defined(__DECC)
[...]
I1 X 938 # pragma __use_linkage __str_link2 (strcmp)
[...]
So, perhaps that #pragma is the
trouble-maker.
> Or use the duct tape of C; lob some
> void-casts at the code.
Adding the semi-realistic "(int (*)())"
before "strcmp" and "strcasecmp" in the "?:"
statement convinces the compiler that they
have the same type, clearing the complaint,
but I'd rather not try to persuade the
program's maintainer that he should add that,
when no one else has this problem.
Casting only "strcmp" (leaving "strcasecmp"
unmolested) seems to fix it, too, so I'm
leaning toward assigning blame to that
mystery #pragma.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-08-2009 07:33 PM
тАО09-08-2009 07:33 PM
Re: HP C V7.3-009 on OpenVMS Alpha V7.3-2, spurious %CC-E-BADCONDIT?
>Casting only "strcmp" (leaving "strcasecmp"
>unmolested) seems to fix it, too, so I'm
>leaning toward assigning blame to that
>mystery #pragma.
just for laughs, what happens if you add
#pragma __use_linkage __str_link2 (strcasecmp)
?
sure it's still code clutter, but it could be hidden in a header.
(sorry, I don't have a compiler handy to test it myself).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-08-2009 08:16 PM
тАО09-08-2009 08:16 PM
Re: HP C V7.3-009 on OpenVMS Alpha V7.3-2, spurious %CC-E-BADCONDIT?
I live to serve.
alp $ gdiff badcondit.c badcondit_2.c
2a3,4
> #pragma __use_linkage __str_link2 (strcasecmp)
>
alp $
alp $ cc badcondit_2.c
= opt_ignore_case ? strcasecmp : strcmp;
..............^
%CC-W-PTRMISMATCH, In the initializer for cmp, the referenced type of the pointe
r value "opt_ignore_case?strcasecmp:strcmp" is "function (pointer to const char,
pointer to const char) returning int [with linkage __str_link2]", which is not
compatible with
"function (pointer to const char, pointer to const char) returning int".
at line number 10 in file ALP$DKA0:[SMS]BADCONDIT_2.C;1
I don't know what this stuff means, but I may
be little more confused than the compiler.
Looking at
"#pragma __linkage" things have to do with
exotic register usage:
[...]
/*
** DEC C RTL Performance (Linkages)
**
** Certain DEC C RTL functions are defined with linkages declared
** which gives the compiler more information as to register usage in
** the implementation.
*/
#if defined(__ALPHA) && defined(__DECC)
# pragma __linkage __str_link1 = (\
__notused(__r1,__r2,__r3,__r4,__r5,__r6,__r7,__r8,__r9,__r10,__r11,\
[...]
So applying one of them to some unsuspecting
function might be unwise in any case.
[...]
#elif defined(__ia64) && defined(__DECC)
/*
** Should define "similar" linkages for ia64, but they cannot be exactly
** the same because the register conventions are different.
** ***TBD for ia64***
*/
#endif
[...]
Might not be such a clever idea after all.
If this stuff makes compatible-looking
functions incompatible, then it might be nice
to get rid of it, or else make it easy for
the user to get rid of it. I hope that that
"Performance" gain was a big one.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-09-2009 06:25 AM
тАО09-09-2009 06:25 AM
Re: HP C V7.3-009 on OpenVMS Alpha V7.3-2, spurious %CC-E-BADCONDIT?
I've verified this by ifdef-ing the linkage stuff into oblivion in string.h.
I don't find a way to disable this stuff, either.
HP C V7.3-009 on OpenVMS Alpha V8.3
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-09-2009 07:45 AM
тАО09-09-2009 07:45 AM
Re: HP C V7.3-009 on OpenVMS Alpha V7.3-2, spurious %CC-E-BADCONDIT?
%CC-E-BADCONDIT, with a little code
restructuring, you can drop it down to a mere
%CC-W-PTRMISMATCH.
alp $ type badcondit_4.c
#include
int main( void)
{
int opt_ignore_case;
int (*cmp) (const char *, const char *);
if (opt_ignore_case)
cmp = strcasecmp;
else
cmp = strcmp;
}
alp $ cc badcondit_4.c
cmp = strcmp;
........^
%CC-W-PTRMISMATCH, In this statement, the referenced type of the pointer value "
strcmp" is "function (pointer to const char, pointer to const char) returning in
t [with linkage __str_link2]", which is not compatible with "function (pointer t
o const char, p
ointer to const char) returning int".
at line number 12 in file ALP$DKA0:[SMS]BADCONDIT_4.C;1
Again, slapping the senseless type cast onto
"strcmp" clears this (milder) complaint.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-10-2009 11:53 AM
тАО09-10-2009 11:53 AM
Re: HP C V7.3-009 on OpenVMS Alpha V7.3-2, spurious %CC-E-BADCONDIT?
For I64, telling the compiler that the called routine doesn't use certain registers in the low 32 register set is interesting, but not very helpful in the longrun as there are ample registers above 32 that will be preserved across the call to strcmp() or strcasecmp().
For indirect routine calls, what should the compiler assume about the target routine's calling conventions? I think the compiler is just trying to avoid getting into trouble. Certainly for these "simple" cases you could make an argument that it could figure it out. You could submit a bug report or enhancement request to see if it could be improved.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-10-2009 12:21 PM
тАО09-10-2009 12:21 PM
Re: HP C V7.3-009 on OpenVMS Alpha V7.3-2, spurious %CC-E-BADCONDIT?
> little carried away.
That was certainly my impression.
> You could submit a bug report or
> enhancement request to see if it could be
> improved.
I (just now) submitted a pointer to this
thread to the "OpenVMS C Product feedback"
Web form, which is about all I can do as a
non-paying peon. My message is important to
them, and, like all such messages, it will be
read. Or so I've been told.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-10-2009 12:41 PM
тАО09-10-2009 12:41 PM