long strings generated by ProC/C++

[Tanya_4]

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.

[Yogeeraj_1]

hi!

can you please post the exact warning message?

thanks
Yogeeraj

[Adam J Markiewicz]

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

[Tanya_5]

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]

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.

[Adam J Markiewicz]

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

[Adam J Markiewicz]

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.

[Tanya_5]

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]

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

[Tanya_5]

I did not have it. After I added one field to the SELECT ProC started generating different code.