Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81149
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.179 as permitted sender)
Message-ID: <54C58DAE.2010402@gmail.com>
Date: Sun, 25 Jan 2015 16:43:26 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: PDO & size_t
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

With recent moving of string lengths to size_t, it looks like PDO APIs
weren't updated. I.e.:

typedef int (*pdo_stmt_get_col_data_func)(pdo_stmt_t *stmt, int colno,
char **ptr, zend_ulong *len, int *caller_frees);

This looks like len should be size_t, and in fact fetch_value() in
pdo_stmt.c sends size_t parameter there, but since I'm not very familiar
with PDO internals, I'd like to double check - is it an omission and
will anything break if I change it to size_t?

There are also other things, like:

	const char		*driver_name;
	zend_ulong	driver_name_len;

typedef int (*pdo_dbh_prepare_func)(pdo_dbh_t *dbh, const char *sql,
zend_long sql_len, pdo_stmt_t *stmt, zval *driver_options);

typedef zend_long (*pdo_dbh_do_func)(pdo_dbh_t *dbh, const char *sql,
zend_long sql_len);

typedef int (*pdo_dbh_quote_func)(pdo_dbh_t *dbh, const char *unquoted,
int unquotedlen, char **quoted, int *quotedlen, enum pdo_param_type
paramtype);

As you can see, sometimes length is an int, sometimes zend_long,
sometimes zend_ulong. This looks like it needs some cleanup.
-- 
Stas Malyshev
smalyshev@gmail.com