On Mon, Sep 19, 2005 at 01:51:38PM -0600, Warren Young wrote:
> A solution we shouldn't overlook is simply changing the SizeType
> definition at the const_subscript_iterator level to 'int'. Negative
> subscripts don't make sense, but the range checking in vector::at() will
> take care of this. Then we don't need ugly overloads, and can avoid the
> risks pps brought up.
I assumed the unsigned int was useful somewhere, but that would indeed be
a useful way to fix it.
One thing to be careful about is whether we need to match types with the
mysql C API. Interestingly, our num_fields() member returns an int already,
where mysql_num_fields() returns unsigned int, so we aren't completely
consistent.
Going in the other direction is important too (calling mysql C API with
an int-converted-to-unsigned), but I hope the C API checks for that too.
The maximum number of columns, as reported here in the comments:
http://dev.mysql.com/doc/mysql/en/table-size.html
is considerably less than an int size. (not that anyone *should* create
the max number of columns)
The max number of rows, however, is a spot we might run into problems.
size_type is used as the return value for result::size(), the number of
rows. It already casts C's my_ulonglong return type to unsigned int.
Going to an int only makes it worse.
- Chris
