HP C RTL routine strncasecmp declaration

[Arch_Muthiah]

Wish you all "Happy thanksgiving and holiday session!!!"...

Env: OpenVMS 7.3-2/Alpha DS10, HP C V6.5.

strncasecmp funtion in string.h( DECC$RTLDEF.TLB) declared as int strncasecmp( const char *, const char *, __size_t)

But the DCL help says int strncasecmp (const char *s1, const char *s2, size_t n)

I have strncasecmp funtion in my HP C program, declared as int strncasecmp (const char *s1, const char *s2, int n).

But I receive compilation error as "strncasecmp" is not compatible with the type of a declaration in DECC$RTLDEF.TLB.

strncasecmp declaration in string.h and DCL HELP shows difference. How to declare this function in my program? It looks me string.h has typo in declaring strncasecmp.


Archunan

[David Jones_21]

You declare it by including string.h, that's what header files are for.

[Arch_Muthiah]

Dave,

You see my declaration syntax, and I have string.h included in my program. But the receive the error "not compatible functions".


Archunan

[John Gillings · Accepted solution]

Archunan,

I'm not sure I understand why you're declaring the routine twice. Once in string.h and once by yourself. Are you trying to substitute your own routine?

string.h is correct. The third argument is of type "__size_t". If you read the code, you'll see that __size_t may be defined as size_t, but the implementation is free to define it as something else.

Look for yourself:

$ LIBRARY/EXTRACT=STRING SYS$SHARE:DECC$RTLDEF/TEXT/OUT=STRING.H

The reason for this is to make the compiler, and hence your code, less likely to be dependent on a particular hardware size for INTEGER or POINTER types (Hext's rule of programming: "One further level of indirection solves all problems")

Please explain why you need to redeclare the function, so I can work out what you're trying to achieve. Maybe post a small, but complete, code example that shows the error (by your description just a few lines will do)

[Arch_Muthiah]

John,
I thought I can get your response tomorrow only since your time now in australia is night, and you will be sleeping. Thanks John for your response at this time.

I did not declare strncasecmp inside program, It is a old DEC C program developed in Alpha OVMS with previous C compiler version, Now I am trying to build.

I found no prototype declaration of strncasecmp function inside the CProg.

They are using this function as.....

int strncasecmp( char *s1, char *s2, int n)

I have already changed that function as ....
int strncasecmp( const char *s1, const char *s2, int n).

This gave compilation error as "strncasecmp is not compatible with the type of a declaration in DECC$RTLDEF.TLB"

So can I use this functions as ...
int strncasecmp( const char *s1, const char *s2, size_t n)?.

Because if I change the 3rd argument as
"size_t n", the compilation successful.

Archunan

[Steven Schweda]

> I did not declare strncasecmp inside
> program, It is a old DEC C program
> developed in Alpha OVMS with previous C
> compiler version, Now I am trying to build.

> They are using this function as.....
>
> int strncasecmp( char *s1, char *s2, int n)

I think that's called declaring the function.

It's not clear from your description, but we
might assume that the old code includes an
actual strncasecmp() function, because it was
not available in older C RTL versions.

If that's true, you can throw it away.

Alternatively, you can bracket the old
function with directives like:

#if __CRTL_VER < 70000000

[old strncasecmp() code]

$endif /* __CRTL_VER < 70000000 */

That way, when the old code is needed, it
will be used, and when strncasecmp() is in
the C RTL, the program will use that one.

There are even more clever methods to improve
portability of the object code, but that's
another lesson.

Look at the header file (string.h) to get the
proper conditionality.

[Arch_Muthiah]

Dear Steve,

> int strncasecmp(char *s1,char *s2,int n)
> I think that's called declaring the
> function.

This is not the declaration statement Steve. also no need to declare any RTL functions inside any program if we include the respective *.h file. There will be a function body after "int strncasecmp()".

I mentioned, after I change the third argument "int n" to "size_t n", the compilation went thru successfully. I asked Mr.John that whether can I change "int n" to "size_t n"?

< Alternatively, you can bracket the old
< function with directives like:
< #if __CRTL_VER < 70000000
< [old strncasecmp() code]
< $endif /* __CRTL_VER < 70000000 */

The latest OS comming with updated RTLs, so
we don't need to worry about __CRTL_VER macro, because the important purpose of this macro is to provide the required C RTL API and to categorise 32 and 64 bit support for the VMS where we compile. the compiler.

Archunan

[Steven Schweda]

It's still not clear.

> [...] no need to declare any RTL functions
> inside any program if we include the
> respective *.h file.

True. So why is there anything like
"int strncasecmp(char *s1,char *s2,int n)"
in your code?

> There will be a function body after "int
> strncasecmp()".

In other words, the old code includes its own
strncasecmp() function? I repeat:

Throw it away.

> [...] we don't need to worry about
> __CRTL_VER macro [...]

Have it your way.

[Steven Schweda]

And after you change the declaration of the
existing strncasecmp() function so that the
compiler is happy, what is your plan for
dealing with the MULDEF camplaints from the
linker? Hint: Throw it away.

[Arch_Muthiah]

Steve,

Looks like you started enjoying the holidays!!!

Steve, please go through your last two responses, I already said compilation went thru successfully. I just asked Mr.John that changing "int n" to "size_t n" will be ok? Nothing more than that. But you yourself trying to get clear something and eating my time. I already cleared that, I use this forum as a alternate to HP support. Not for unneccessary arguments.

There are so many things involved using RTL functions, user written functions, functions overloading and using C++ compiler to compile CProg. Now I don't have time, if I have problem, certainly I will be with those type of questions.

Have a peacefull holiday session!!!

Archunan

[John Gillings]

Archunan,

> since your time now in australia is night,

Maybe it's a different Australia from the one you're thinking of ;-) It's definitely day here. Both now, and when I responded earlier :-)

I have to strongly agree with Steven, you should simply remove all declarations of strncasecmp from your code. Indeed, all lines of code than mention strncasecmp, except those that are calling it. Just make sure you have:

#include

and it should all "just work".

[Arch_Muthiah]

Dave/John/Steve,

Thanks for your time.
after I changed the third arg from "int n" to "size_t n", the compilations was successfull.

I wanted to give minus point to Steve for his unnecessary interruption without concerning about to my question, but there is no 'minus point' option for that.

Though I need confirmation from John, I wanted to close this thread urgently, otherwise I will be flooded with Stev'e unnecessary questions and blaming.

Thanks
archunan

[Arch_Muthiah]

Sorry John for 0 point.

I asked some other thing. The question left unanswered was about changing "int n" to "size_t n".


Archunan

[Steven Schweda]

> The question left unanswered was about
> changing "int n" to "size_t n".

The answer was:

"[...] [Y]ou should simply remove all
declarations of strncasecmp from your code."

You didn't seem to like that one (from him or
from me), but that's the answer.

[Arch_Muthiah]

Amazing!!! Steve. you are too much responsible!!! for each every psoting on this forum.

Yesterday itself, I compiled, linked, and tested. Now I am out of that CProg.

If you have any doubt or if you don't like my CProg to work or if you interested in arguments, I am not available to arguments, but you can catch HP support personal for your new doubts, or lodge a complaint with HP on "how can Archunan's CProg be worked".

Please don't drag me further on this thread.

Archunan

[John Gillings]

Archunan,

>Please don't drag me further on this thread.

Sorry, I have to agree with Steven on this. You asked for our advice, we gave it, but you're now arguing why you're right and we're wrong!

If your program still contains any definition for strncasecmp then it's wrong. Plain and simple. Yes it might compile cleanly and "work" now, but that doesn't make it correct. Sometime down the track it may stop working. If you remove the definition(s), your program will be correct, and it will continue to work in future versions.

Hint... if you don't like the advice, that's your business, but the way you've responded in this thread will make me think twice before taking up my time composing answers to your future questions.

[Arch_Muthiah]

John, why are you mad at me?

I always have good impressions on you, infact when I post my question, I was expecting any suggestions especially from you.

please go thru my responses, Before I see your first response, I mentioned my Cprog compiled successfully after changing "int n" to "size_t n". After this, I saw your response, but anyway I assigned points for your response; respecting your valuable time and suggestions.

I started this thread with "I receive
--COMPILTION-- error as strncasecmp is not compatible with the type of a declaration in DECC$RTLDEF.TLB". Please do go through Mr.Steven responses, he has entered after I said "no compilation error"; after everything is solved, he tries to create new questions where I need no advices and clever lessions. I observe from starting onwords, he loves arguments and blaming other members. Instead of concentrating and blaming others members responses, he better can concentrate giving suggestions on the intial customer's question. Forum members posting their questions with the expectations of getting quick answer (quicker than HP customer support or going through our HP excellent documents). If we argu on each other's answers irresponsibly, then one our forum member who waits for answer, will lose his one customer.

even now I would like to use/respect this forum as alternate to HP support, not for any --ARGUEMENTS and BLAMING --, there are so many forums in the net for arguments, blaming and technical research. But I would like "THIS FORUM" to be difft.

Bear with me John if my expectations from this forum differs.

Archunan

[Steven Schweda]

> John, why are you mad at me?

Why do take a simple correction as a personal
insult?

> Please do go through Mr.Steven responses,
> he has entered after I said "no
> compilation error"; [...]

Note that _I_ was the first one to mention
linking. You initially said it had been
compiled, not that it had also been linked.

As most of us are not members of the Psychic
Friends Network, we are forced to work with
the information you give us, not with all the
information you might have.

Mr. Gillings was correct (as was I) when he
said that there is no good reason for you to
have any declaration of strncasecmp() in
your program. I'm sure that we would all be
open to a good counter-argument, but I don't
expect one. As always, you are free to
ignore any advice you get here, no matter
how good (or bad) it might be.

> How to declare this function in my program?

"If does it, you don't do it!" is
still the right answer, what ever you think
of me (or anyone else) personally.

My personal advice would be, "Grow up.", but
you're free to ignore that, too.

[Jan van den Ende]

Archunan, Steven, & John,

Maybe it will be better if you all take a 24 hour timeout before reacting again.

To all 3:
From the sideline it looks like your deepest arguments are linguistic.
Please try to get the intensions behind each others postings, before reacting to your own interpretations of the literal text.
I know that is more difficult, but clearly we all do not have the same agility with English. Foreign languages CAN pose extra problems!

Please - no more personal attacks in this forum.

Oke?

Proost.

Have one on me.

jpe

PS - Zero points for this, please.

[Steven Schweda]

Are you doing anything interesting with the CC
options /PREFIX or /STANDARD? That could
affect the results.

[Arch_Muthiah]

Steve,

My C prog compilation (using C++) qualifier is

/list/mach/noopt/debug/define=("vms")/prefix=except=strnncasecmp/nomember/assume=noaligned_obj.

I like to use this /prefix=except="AnyDuplicateRTL", because if I suggest for modification as you suggested, it is a big modification work for almost 9000 programs. The "type" and "size" of those arguments used in the duplicate RTL functions, are being used in so many places throught so many programs.

As everything is a business, I did not want to disclose this in this forum. I am sorry if my posting hurted any one.

Thanks Steve
Archunan

[Steven Schweda]

> /prefix=except=strnncasecmp

That explains why you did not get the LINK
problems I expected. This means that you are
still using your own strncasecmp(), not the
one in the (new) C RTL.

> if I suggest for modification as you
> suggested, it is a big modification work
> for almost 9000 programs.

The modifications I suggested should have
been limited to two files:
1. Where the actual strncasecmp() function
code was.
2. The (non-system) header file where
strncasecmp() was declared (before it
appeared in ).

If you need to change any more files, then
you might think about restructuring the
code.