Re: To the moderator

In article <353FCB04.B87CD05C_at_fairway.com>

           jcann_at_fairway.com "Jeffery Cann" writes:

>Kaz Kylheku wrote:
>>
>> In article <353F8A87.1CD0BA96_at_fairway.com>,
>> Jeffery Cann <jcann_at_fairway.com> wrote:
>> >> You can't do embedded SQL in C and still call it C. So your question has
>> >> nothing to do with the C language.
>> >
>> >Really? Then why does my processed ESQLC code "look and feel" like C.
>>
>> The syntax of C isn't defined by look and feel.
>
>That was a joking remark, hence the smiley face.
>
>> ESQLC isn't C, it's a language based on C.
>
>Granted, the point is that ESQLC is precompiled into C function calls
>and assignments. This code is then compiled by a C compiler and linked
>into an executable with other C objects and libraries. This sure seems
>like C to me.
>
>For example:
>
> /* Here is an ESQLC statement */
> /* Sent to the precompiler */
> EXEC SQL
> SELECT RESERVATIONS_SEQ.NEXTVAL
> INTO :reservation2:ind1
> FROM DUAL;
This doesn't even have valid C syntax. If this is the source code in question it has no meaning as far as the C language is concerned, there's no point in asking about it in comp.lang.c.

>
> /* Here is the C code that the precompiler */
> /* generated from the above ESQLC code */
> {
> struct sqlexd sqlstm;
>
> sqlstm.sqlvsn = 8;
> sqlstm.arrsiz = 2;
> sqlstm.stmt = "select RESERVATIONS_SEQ.nextval into :b0:b1
> from DUAL
>";
> sqlstm.iters = (unsigned int )1;
> sqlstm.offset = (unsigned int )24;
> sqlstm.selerr = (unsigned short)1;
> sqlstm.cud = sqlcud0;
> sqlstm.sqlest = (unsigned char *)&sqlca;
> sqlstm.sqlety = (unsigned short)0;
> sqlstm.sqhstv[0] = (unsigned char *)&reservation2;
> sqlstm.sqhstl[0] = (unsigned int )4;
> sqlstm.sqindv[0] = ( short *)&ind1;
> sqlstm.sqharm[0] = (unsigned int )0;
> sqlstm.sqphsv = sqlstm.sqhstv;
> sqlstm.sqphsl = sqlstm.sqhstl;
> sqlstm.sqpind = sqlstm.sqindv;
> sqlstm.sqparm = sqlstm.sqharm;
> sqlstm.sqparc = sqlstm.sqharc;
> sqlcxt((void **)0, &sqlctx, &sqlstm, &sqlfpn);
> if (sqlca.sqlcode < 0) goto sql_error;
> }

Without a definition of struct sqlexd, sqlcxt() and other things this code is essentially meaningless as far as C is concerned - its behaviour isn't well-defined. It only makes sense to talk about these in a context where they are well-defined. That would only be comp.lang.c if the question included an adequate description of them, and the question was about C issues arising from this (like the portability of some of those casts).

>> Why don't we admit C++ questions too? After all, there exists CFRONT,
>> which translates C++ into C. Then there are f2c and p2c, so
>> Fortran and Pascal are on topic as well! Eiffel, anyone?
>
>I agree that any Oracle questions concerning Pro*C are best left in
>comp.databases.oracle.tools or comp.databases.oracle.misc. My point is
>that the Pro*C precompiler generations C code.

So what? C compilers generate assembly code or machine code. That doesn't mean that assembly language newsgroups are the place to talk about C issues. If the question is about the correctness of the translator output then fair enough, otherwise the target language is irrelevant.

>> >The ESQL is translated into Oracle C library calls. Granted, the
>>
>> Translated by something other than a C implementation, into an undoubtedly
>> platform-specific C program which relies on features that aren't part
>> of the language.
>
>In fact, it is platform independent, because the platform code is
>abstracted by the calls to the Oracle libraries.

Which makes it specific to those platforms for which relevant Oracle libraries exist. Also, as noted before, there may be portability issues relating to the generated code (which is a C issue).

> Oracle handles the
>platform-specific issues. Now, you would have to re-precompile a pro*c
>file if you move it from one platform to the other, so if your
>definition of platform-dependant falls here, then fine.

No, even standard, portable C needs to be recompiled on different platforms.

>> >Oracle-generated code as some strange usage, but it is still C. It even
>> >can generate ANSI C.
>>
>> I doubt it, since it most likely relies on libraries that are not part of ANSI
>> C which enable it to communicate with the database system.
>
>This may not be the case. We would have to see exactly what the code in
>these libraries looks like.

Take sqlcxt() above.It isn't a standard C library function. No truely portable C code can call it unless *you* have as part of the program portable source code for sqlcxt(). If you don't have the source code then whether sqlcxt() is originally written in portable code or not is not relevant since you don't have the means to port it.

>In addition, I am fairly certain that the
>Oracle libraries are written in C and are using the C standard library,
>unless Oracle decided to write their own libraries to replace the
>standard C library. This doesn't seem particulary pragmatic, given the
>cost of producing (i.e., duplicating) the standard C library.

I doubt whether the Oracle libraries could be written entirely in terms of the standard C library. The problem is that that doesn't provide any locking or other means to create serialisation mechanisms. Also performance tends to be mportant for databases so commercial DBMSs tend to make use of whatever platform-specific magic is available to squeeze out that last bit of performance.

>> Any question about such libraries would not be topical for comp.lang.c.
>
>Here's where we diverge.

If your question is about behaviour that the C language doesn't define then comp.lang.c is the wrong place to discuss it. C doesn't define the behaviour of non-standard library functions.

>> What you probably mean is that the tool will generate C which uses function
>> prototypes.
>
>Yes, that is what I meant.
>
>The other point I want to make is that unfortunately for people who work
>on applications that contain ESQLC, the comp.databases.oracle.tools and
>comp.databases.oracle.misc does not have 1/10th the experience in coding
>C that comp.lang.c readers do. If they do have more experience, the
>postings don't show it.

If the question is ultimately about C then there's no problem as long as adequate background is given. If the question is about Oracle the no amount of C knowledge and experience is going to help.

>I suspect that the experienced C programmers who work with Oracle don't
>read any oracle newsgroups, only comp.lang.c. I suspect this because I
>once posted a question about unsigned chars in oracle structures to
>comp.lang.c and recieved numerous replies.

Well, that might have been a question about C. Word it right and it may look very much like a C question! :-)

>In addition, the majority of the questions in these oracle groups are
>about Developer/2000 (GUI forms toolkit), not Pro*C.
>
>So, as a newsgroup poster, you have 2 options:
>1) post to comp.lang.c and usually get an coherent answer from someone
>who does not read comp.databases.oracle.tools

If it is a question about how the Oracle libraries behave I suspect that you would be redirected to an Oracle newsgroup. I don't see many database questions being asked (let alone answered) in comp.lang.c.

-- 
-----------------------------------------
Lawrence Kirby | fred_at_genesis.demon.co.uk
Wilts, England | 70734.126_at_compuserve.com
-----------------------------------------