[Phpmyadmin-devel] Re: Parser and PHP3

[Robin Johnson]

On Thu, 25 Jul 2002, Loïc wrote:
> Your parser is a great job :)
Thanks. I tried to test it out as throughly as possible.

> Marc just submitted for me some changes in your
> files. They are just related to coding standard
> problem except a "foreach" I replaced by a while
> for PHP3 compatibility.
Ok.

> At the beginning of "sqlparser.lib.php3" there
> is a constant I renamed from "DEBUGTIMING" to
> "DEBUG_TIMING" but I can't find where it is
> defined. I you can change it...
DEBUG_TIMING and the strange order of function declaraction inside that
block is related to my testing harness for the SQL Parser. I'm going to
keep the testing harness and those calls there for the moment, while the
analyzer and tweaking the Parser is in progress, and probably remove it
around 2.3.2 or 2.3.3 once everything has totally stabilized out.

> Now let's talk about PHP3 compliance problem
> in "sqlparser.lib.php3":
>
> 1. I suggest to replace lines 168-170 by
>      $pos    = strpos(' ' . $sql, $quotetype, $oldpos) - 1;
>      if ($pos < 0) {
>    Could you check if it works this way?
No. This does NOT work, as we already start at $oldpos instead of zero.
Instead, this works:
$pos = strpos(' ' . $sql, $quotetype, $oldpos + 1) - 1;
if ($pos < 0) {

Merged in CVS.

>    It seems this is the only strpos call where we should
>    do different things depending on "not found" and "found
>    at the begenning of the string". Am I right?
Presently yes, but I never did complete all of the error detection
functions.

> 2. "trigger_error" is a PHP4 function. Couldn't we use
>    "PMA_mysqlDie()" instead?
This is a problem actually. I don't want to terminate the running of the
page just because my SQL Parser can't handle something in the query. I
wanted to just print out a message as to why my parser failed and continue
execution of the page contents. triggering an error with NOTICE level so
that it just prints a message seemed suitable at the time, but I think we
might want to convert to just having a global variable with an error
message for the parser subsystem. Like I said, I never completed the query
error detection at all.

> 3. "print_r" is also a PHP4 function. I suggest to display
>    the array "manually".
I was actually just dumping the contents of the analyzer data while I was
working on it. In the end, that function won't be printing any data at
all, but returning it instead.

I've changed that to just return the array for now, and I'll print it out
from my test harness instead.

Merged in CVS.

> 4. "gzcompress" and "gzcompress" can't be used with PHP3 and
>    must be tested before use in PHP4 ie
>        if (function_exists('gzcompress'))....
I wanted a method in which I could get a specific data dump from a user
containing all the information I needed to fix the SQL Parser.

Just dumping the data base64 encoded got really big, so I was just running
it thru gzcompress before doing the base64 encoding.

Any ideas how I could still shrink the size for the bug posting ?

Considering this, I actually had a major idea. The linux kernel has a
'BUG()' call. For some of our PMA code, a similar thing would actually be
a very useful function call.

Ideally it would print out a human readable message about the bug first of
all, probably in the current language, then a gzip+base64 data chunk, with
instructions to post the chunk on the Bug tracker (maybe even a 'post'
link that partly auto-fills the form ?).

The data chunk can contain whatever we will need in each case. In my
existing use of it, I have a CVS $Id$ tag included for version tracing.

-- 
Robin Hugh Johnson
E-Mail     : robbat2 at orbis-terrarum.net
Home Page  : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ#       : 30269588 or 41961639