List:MySQL++« Previous MessageNext Message »
From:Jose Mortensen Date:September 24 2004 5:02pm
Subject:Re: Re: query.store, query.exec might yield in segmentation fault - Warren Young, September 24
View as plain text  
Warren,

From the mysql C api documentation:

21.2.12.1 Why mysql_store_result() Sometimes Returns NULL After
mysql_query() Returns Success
It is possible for mysql_store_result() to return NULL following a
successful call to mysql_query(). When this happens, it means one of the
following conditions occurred:
* There was a malloc() failure (for example, if the result set was too
large).
* The data couldn't be read (an error occurred on the connection).
* The query returned no data (for example, it was an INSERT, UPDATE, or
DELETE).

In the function:
Result connection::store(...)
{
....
return ResUse(mysql_use_result(&mysql), this);
}

That return might not be a good idea, not only if the query returns no data,
but it might also return null for other reasons as shown above. Maybe they
are catched somewhere else..... Anyways So I have modified connection and
Result to avoid a segmentation fault if no result is returned. I hope It
does not have a side effect. The patch is...

--- mysql++-1.7.15/sqlplusint/connection.cc 2004-08-20
17:28:14.000000000 -0400
+++ ../mysql++-1.7.15.patched/sqlplusint/connection.cc 2004-09-24
12:29:53.000000000 -0400
@@ -145,7 +145,11 @@
if (!Success)
if (throw_excptns) throw BadQuery(error());
else return Result();
- return Result(mysql_store_result(&mysql));
+
+ MYSQL_RES * res = mysql_store_result(&mysql);
+
+ if (res) return Result(res);
+ else return Result();
}
ResUse Connection::use(const std::string &str, bool throw_excptns) {
--- mysql++-1.7.15/sqlplusint/result1.hh 2004-08-24 00:51:58.000000000 -0400
+++ ../mysql++-1.7.15.patched/sqlplusint/result1.hh 2004-09-24
12:31:32.000000000 -0400
@@ -170,7 +170,7 @@
}
//: Raw c api function
- int num_rows() const {return mysql_num_rows(mysql_res);}
+ int num_rows() const {if (initialized) return mysql_num_rows(mysql_res);
else return 0;}
//: Raw c api function
void data_seek (uint offset) const
{mysql_data_seek(mysql_res, offset);}


----


Jose Mortensen wrote:
>
> I know it should use exec instead, but:

...but you want to be able to misuse the library, and have it read your
mind as to what you really meant, right?

> 1. C++ code should never produce a segmentation fault.

C++ code that does not contain bugs should never produce a segfault.
Your code contains a bug.

> 2. In some cases like, for example, a user console program where the
> query is user defined, it is difficult to predict if the query should
> return something or not. In cases like that better to return an empty
> result. I think.

So what you're saying is, you want me to write a SQL parser that can
find out enough about the query that it can call exec() or store()
depending on what kind of query it is...so you don't have to write one
yourself.  Is that right?

There are two different APIs here because they are very different
operations.  That's necessary complexity, if we are to avoid writing a
SQL parser.

> My preference is to return an empty result.

Patches thoughtfully considered.

Thread
Re: Re: query.store, query.exec might yield in segmentation fault - Warren Young, September 24Jose Mortensen24 Sep
  • Re: query.store, query.exec might yield in segmentation fault - WarrenYoung, September 24Warren Young24 Sep