Re: To the moderator

In article <3545CF74.187D_at_bedrockcomputers.demon.co.uk>

           steve_at_bedrockcomputers.demon.co.uk "Steve mouatt" writes:

>Lawrence Kirby wrote:
>>
>> In article <353FCB04.B87CD05C_at_fairway.com>
>> jcann_at_fairway.com "Jeffery Cann" writes:
>>
>[snip]
>
>
>> >> >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.
>The fact that a program utilises libraries other than the standard one
>does not mean that it is not a ANSI C program. After all the standard
>library may well use functions from a platform specific library its
>self. It may not be portable but that is not the same thing.

The standard library functions are unique that their behaviour is defined by the language itself. No other functions have well-defined behaviour in ANSI C unless their source code is compiled as part of the program.

For example if I use a Unix function like fork() or a Windows function like GetMessage() I'm no longer writing in ANSI C. I can call functions such as printf() because those functions are defined by the standard. It doesn't matter how standard library functions are implemented because those details are not visible to the program, they simply have to have the correct behaviour.

>> >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.
>The only plaforms that such a program can be supported is one that is
>supported by Oracle.

Exactly.

>Since on Oracle supported platforms the PRO*C
>translator will produce this code and provide the libraries containing
>sqlcxt or it equivilents there is no need to port it one self.

The point is that it is tied to Oracle, it isn't portable to any ANSI C implementation.

...

>The process of compiling a PRO*C program involves the pre-processing of
>the PRO*C with some C pre-processing included within it, the normal C
>pre-processing followed by the C compilation. The interaction between
>these stages often mean that errors do not appear until the final stage.
>The programmer is than faced with the question of whether the cause of
>the error lies in the C code that they have written or the C code that
>was generated. Under these circumstances looking at the generated C
>output is often the best way to locate the error and then back tracking
>to the actual cause.
>
>Herein lies the problem that we have seen here. If you can't locate the
>error and need advice who do you turn to? Is it a C problem or a PRO*C
>problem? It must be said that PRO*C does really try hard to produce ugly
>code and this is likely to offend most C programmers but unfortunatly it
>also confuses the less experienced even more.

It is reasonable to ask questions in comp.lang.c about C issues relating to the intermediate C code. However present it as a C question and provide any background information necessary so that somebody not familiar with Oracle can see what you're getting at. There's no reason to believe that comp.lang.c readers will know about or want to discuss Oracle related issues, just as comp.databases.oracle.misc readers probably aren't interested in discussing the finer points of C syntax.

In fact separating out the issues in this way can be a useful step in understanding and diagnosing a problem.

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