Databases
cancel
Showing results for 
Search instead for 
Did you mean: 

long strings generated by ProC/C++

Tanya_4
Occasional Visitor

long strings generated by ProC/C++

I have a problem compiling Pro C/C++ program containing SELECT which after preprocessing creates a string longer then 1024 (maximum of string literal generated by the preprocessor). In this case, the preprocessor has to divide this string and concatenate at run time. It does not happen with my program. In generated C program, I can see a function call where the second parameter is the string with my SELECT with cut ending. It looks that the program still executes correct SELECT, but I am getting a warning from C compiler that the string data type is implicitly deprecated to (char *). I have noticed that generated C programs are different depending on the length of the SELECT. I am not sure that the results of execution will be always correct and I can just ignore this warning.
11 REPLIES
Yogeeraj_1
Honored Contributor

Re: long strings generated by ProC/C++

hi!

can you please post the exact warning message?

thanks
Yogeeraj
No person was ever honoured for what he received. Honour has been the reward for what he gave (clavin coolidge)
Adam J Markiewicz
Trusted Contributor

Re: long strings generated by ProC/C++

Hi

I'm not sure, but I guess you mix several things together. Refreshing my adventures with ProC I'm _guessing_ that:

1. I'm not sure if you don't mix 'preprocessing' with 'precompiling'. I always used 'preprocessing' for C preprocessor and 'precompiling' for ProC.

2. ProC does not produce strings concatenated at runtime, as it would involve dynamic buffer managment, which would be complicated and sensless in this situation, as all queries have to be completely defined in precompilation stage.

3. ProC can divide long strings into several smaller parts, but it does it only for estetical reasons. As between these strings should be no operator it will be concatenated by the C compiler again in _compilation_ stage.

Example:
puts( "This "
"is "
"divided "
"string." );

4. Warning about implicitly depreciation to (char*) comes from the fact, that strings generated by the ProC (and any other such string) is predeclared by the compiler to (const char *) - I guess even to (const char[]). The functions that are used are declared as having (char *) argument and this implicitly omited const gives you the warning.

Hope I helped.
HTH
Good luck.
Adam
I do everything perfectly, except from my mistakes
Tanya_5
Occasional Visitor

Re: long strings generated by ProC/C++

The message is
"Warning 829: "BFBPI_Account_Iterator.c", line 800 # Implicit conversion of string literal to 'char *' is deprecated.
"select C.BILL_ITEM_SEQ_ID ,C.SVC_DESC_TX ,C.VPN_ID ,TO_CHAR(C.S"

I am attaching two fragments of code generated by the precompiler (sorry, Adam) from the same ProC/C++ program. The difference in two source codes was only in the number of fields being selected.
Jairo Campana
Trusted Contributor

Re: long strings generated by ProC/C++

example problems:aCC -D_PTHREADS_DRAFT4 -D_REENTRANT -D_HPUX_SOURCE small.c -lcma
Warning 829: "small.c", line 25 # Implicit conversion of string literal to
'char *' is deprecated.
portname = "/dev/ttypa";



The problem is with the select(2) statement and the second parameter.
As per the 10.10 Release Notes some of select(2) parameters have been
changed from an "int *" to a "fd_set" which is a struct. You can see the
prototype definition in sys/time.h and view the new man page as in
man 2 select.
The problem comes from the fact that /opt/dce/include/dce/cma_ux.h,
which
is referenced because of the inclusion of pthread.h, still has the "old"
prototype definiton of select(2).


If using libcma.1 and user threads a potential work-around is to use a
cast as in "(int*) fd_set" but this must be done with care.

There is a current bug report filed for this problem. It is:
JAGad24804:
"The definition of cma_select() in cma_ux.h needs to be corrected"


ALT KEYWORDS
cma_select cma_ux.h warning 604: Pointers are not assignment compatable bad argument 2 type for cma_select(): Argument type 'fd_set *' does not match select(2)

--------------------------------------------------------------------------------
You may provide feedback here

To help us improve our content, please provide feedback and any additional comments below. If you have a problem or a question that needs immediate attention, please submit a call or contact your HP Response Center instead.

legionx
Adam J Markiewicz
Trusted Contributor

Re: long strings generated by ProC/C++

Hi again

ad.1.
No problem. I just wanted to be sure what's the problem. C preprocessor can also have its limits.

ad.2.
Looks like it really does things differently, so I was wrong. I've never produced a query longer than 1024 bytes. However in the second case in your attached source I cannot find the definition of the ctx object nor sq0001 - does it contain the full query or only the rest of it?

ad.3.
I was wrong. As can be seen string division is made with usage of backslash.

ad.4.
Looks like I was wrong. The warning comes because usage of new function was introduced. I guess ProC assumes that Literal strings are predeclared as (char*), not (const char*). As there is no casting and as the function seems to be declared with (char*) for the second parameter you receive this warning.
To be sure you could try to look for the declaration of the function (I guess it could be in sqlca.h). Even more - I think you could even modify the declaration of this function from (char* to (const char*) and have no warning any more. Declaring arguments this way is supposed to tell the C compiler that function will not modify the string via this pointer.

Hope it helps.
Good luck
Adam
I do everything perfectly, except from my mistakes
Adam J Markiewicz
Trusted Contributor

Re: long strings generated by ProC/C++

Correction.
I meant that ad.4. I was right, of course...
I got used too much to be wrong. :)

As this was your primar question I hope it will help you.
I do everything perfectly, except from my mistakes
Tanya_5
Occasional Visitor

Re: long strings generated by ProC/C++

Probably I did not explain my problem properly. I understand why I am getting error message from C compiler. It is because the prototype of the function it references is "void sqlbuft(void **, char *);". I could do type casting to (char *) if 1) it was not generated by ProC code and I had access to it, 2) it was correct code. The second parameter in the call to sqlbuft function is not complete select, it should have "STATUS=0" in the end. The code generator just cuts the string after 1024 bytes. According to "ProC/C++ Precompiler Programmer's Guide" "Strings that exceed the length specified by MAXLITERAL are divided during precompilation, then recombined at run time". I've seen successfully compiled code with the select longer then 1K where two strings
static const char *sq0001 and
static const char *sq0002 were generated
I am not sure that my precompiler generates correct code and that it will always give correct results at run time.
Adam J Markiewicz
Trusted Contributor

Re: long strings generated by ProC/C++

Hi again

From the practical point of view:

If the query is not rejected it means it is valid and I guess query which ends with 'T.STAT' would be rejected. So I guess if you receive correct result once there should be no reason not receiving it in the future. Other more probabile case would be not receiving any data and having error on executing query.

Another thing, which I must repeat: You did not attach sq0001 in the second case. So what can anyone say without knowing it?

Good luck
Adam
I do everything perfectly, except from my mistakes
Tanya_5
Occasional Visitor

Re: long strings generated by ProC/C++

I did not have it. After I added one field to the SELECT ProC started generating different code.
Adam J Markiewicz
Trusted Contributor

Re: long strings generated by ProC/C++

Hi again

I'm surprised.
So where this comes from?

>>
:b7) and T.CYCLE_RUN_YEAR=:b8) and T.STAT");
sqlstm.stmt = sq0001;
<<

Mayby this will contain any clue?

Also I wouldn't give up the 'practical path'.
Try to prepare a long query with very important statement at the very end. Ensure that this part was cut off by the precompiler. Then check the results. If your statement was active it means it is done somehow differently, but properly. If it was ignored - you have to investigate more (mayby even try to contact the ProC helpdesk).

Good luck
Adam
I do everything perfectly, except from my mistakes
Tanya_5
Occasional Visitor

Re: long strings generated by ProC/C++

Oh, yes, Adam, you are right! sq0001 has the end of the select:
static const char *sq0001 =
"US='0') ";

I ran the test, which you are asking me to do, and could not understand why the SELECT works. Now I can just ignore the warning message.

Thank you very much, Adam.
Good luck.