Re: Easy steps to PANIC a server

On Wed, 2 Dec 1998, Wallick, Steve wrote: > The following example will get through the pre-processor and compile process > without error. And so it should; the ESQL/C pre-processor cannot tell that you didn't write what you intended to right. You can use: EXEC SQL DECLARE dlTc CURSOR FOR ...; EXEC SQL DECLARE "dlTc" CURSOR FOR ...; EXEC SQL DECLARE :dlTc CURSOR FOR ...; All three are valid; the first two probably name the same cursor; the third may not, depending on the value stored in the dlTc host variable. > Does anybody have a parser which will catch this type of error. Not personally. > If we develop our own, what are the rules of order and scope?? There are no rules of order or scope, really. Cursor and statement names are global, and can be identified by the value in the string variable, or by a string literal, or by an unadorned identifier which is converted into a string literal. At run time, a given statement name must be prepared before you can declare a cursor for that name; there are no lexical rules about where the prepare and declare have to appear. Essentially, you are asking for an analysis which is not computationally feasible without executing the program. It is reasonable to infer that, within the scope of a single function, the following code is erroneous: int function(...) { ... EXEC SQL DECLARE c_name FOR s_name; ... EXEC SQL PREPARE s_name FROM :s_text; ... } but even that inference depends on what else is in the function and on how it is used. For example, the following would be valid, provided the A_PREPARE operation was invoked before the A_DECLARE operation. int function(...) { ... switch (action) { case A_DECLARE: EXEC SQL DECLARE c_name FOR s_name; break; case A_PREPARE: EXEC SQL PREPARE s_name FROM :s_text; break; ... } ... } In the pre-5.00 days, life was much simpler; the PREPARE had to lexically precede the DECLARE, and the cursor names could only be unadorned identifiers, and the names were local to a single source file. All three restrictions were removed with 5.00. Of course, you could decide that your coding standards are different, and generate some parser which would warn you about the misuse the cursor and statement names according to your revised rules, but that would be hard, and could give invalid warnings. That is, it might give a warning for code which was dubious by its rules but which would work at run time. > We are compiling 16 bit Windows client code with > > INFORMIX-EMBEDDED SQL for C Version 5.01.W and VC 5.0 > > and executing against a 7.24 SUN engine. The following code illustration will > cause a server panic. > > // declaration for a dynamic cursor as advised by Tech Support > $char szBuffer[300]; > $char dlTs[] = "dlTestSel_qid"; > $char dlTc[] = "dlTest_Cursor"; > sprintf(szBuffer ,"select ..."); > > // Prepare the string > $prepare $dlTs from $szBuffer; > > // oops forgot the $ -- using a static cursor > $declare dlTc cursor for $dlTs; > > // still using the static cursor > $open dlTc; > $fetch dlTc into $dtHolder; > $close dlTC; > > // free the dynamic cursor (which was not declared) > $free $dlTc; > > We do not free the static cursor ( dlTc ). Execute enough times and a panic > ensues. Yours, Jonathan Leffler (jleffler@informix.com) #include <witticism.h> Guardian of DBD::Informix v0.60 -- http://www.perl.com/CPAN Informix IDN for D4GL & Linux -- http://www.informix.com/idn